1
0
Fork 0

Fix a possible crash in thread_is_available()

When we have more then 2 threads then we do an array
access with index 'Threads[slave].activeSplitPoints - 1'
This should be >= 0 because we tested the variable just
few statements before, but because is a shared variable
it could be that the 'slave' thread set the value to zero
just after we test it, so that when we use the decremented
variable for array access we crash.

Bug spotted by Bruno Causse.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>
sf_2.3.1_base
Marco Costalba 2010-01-25 22:18:12 +01:00
parent dac1bcab90
commit 5ca4284027
2 changed files with 9 additions and 4 deletions

View File

@ -2898,7 +2898,10 @@ namespace {
if (!Threads[slave].idle || slave == master)
return false;
if (Threads[slave].activeSplitPoints == 0)
// Make a local copy to be sure doesn't change under our feet
int localActiveSplitPoints = Threads[slave].activeSplitPoints;
if (localActiveSplitPoints == 0)
// No active split points means that the thread is available as
// a slave for any other thread.
return true;
@ -2906,8 +2909,10 @@ namespace {
if (ActiveThreads == 2)
return true;
// Apply the "helpful master" concept if possible
if (SplitPointStack[slave][Threads[slave].activeSplitPoints - 1].slaves[master])
// Apply the "helpful master" concept if possible. Use localActiveSplitPoints
// that is known to be > 0, instead of Threads[slave].activeSplitPoints that
// could have been set to 0 by another thread leading to an out of bound access.
if (SplitPointStack[slave][localActiveSplitPoints - 1].slaves[master])
return true;
return false;

View File

@ -64,7 +64,7 @@ struct SplitPoint {
struct Thread {
SplitPoint *splitPoint;
int activeSplitPoints;
volatile int activeSplitPoints;
uint64_t nodes;
uint64_t betaCutOffs[2];
bool failHighPly1;