OsiClpSolverInterface::modelCut() is not threadsafe

Question

OsiClpSolverInterface::modelCut() is not threadsafe

tosttost opened this issue 3 years ago · comments

In line 3262

static int debugMode = 0;

this global variable is then modified in line 3443. It is unclear to me when/whether this line is executed. If it is and another thread B is running modelCut it is definitely possible that debugModel was not initialized in line 3296, thread A sets debugMode to a value != 0 and thread B calls functions with an uninitialized this pointer (e.g. line 3454) causing undefined behaviour or a segmentation fault.

OsiClpSolverInterface::modelCut is used by Cbc.

John Forrest · Answer 1 · Fri May 14 2021 02:37:14 GMT+0800 (China Standard Time)

As the name suggests, this is only used for debugging - which would be done without threads - normally in a debugger when it would be set by debugger.

…

On 13/05/2021 18:18, tosttost wrote: In line 3262 |static int debugMode = 0; | this global variable is then modified in line 3443. It is unclear to me when/whether this line is executed. If it is and another thread B is running modelCut it is definitely possible that debugModel was not initialized in line 3296, thread A sets debugMode to a value != 0 and thread B calls functions with an uninitialized this pointer (e.g. line 3454) causing undefined behaviour or a segmentation fault. OsiClpSolverInterface::modelCut is used by Cbc. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#191>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWJYHCLZALNVNXADO2ISGLTNQCU3ANCNFSM4425OXWQ>.

tosttost · Answer 2 · Fri May 14 2021 17:41:00 GMT+0800 (China Standard Time)

this is only used for debugging

I do not claim anything else. But I'm pretty sure the current implementation is not thread safe no matter if you are debugging or not.

debugMode = 0 does skip all the 'if' that modify 'debugModel'. Nevertheless debugMode is modified if modelPtr_->numberColumns_ < 0 no matter what value it had before or if we are running a debug or a release build. After that happend, the 'if' are no longer skipped.

So unless

modelCut() is only called in debug builds - seems unlikely to me
or 'modelPtr_->numberColumns_ < 0' never happens in release builds

the current implementation is not thread safe in release builds, although the bug will be quite difficult to trigger.

John Forrest · Answer 3 · Fri May 14 2021 19:16:03 GMT+0800 (China Standard Time)

On 14/05/2021 10:41, tosttost wrote: So unless * modelCut() is only called in debug builds - seems unlikely to me * or 'modelPtr_->numberColumns_ < 0' never happens in release builds

I think I can guarantee that modelPtr_->numberColumns() will always be positive. I don't wish to lose some of that debugging code, but I will take out the lines if (numberColumns < 0) debugMode = -numberColumns; John Forrest

tosttost · Answer 4 · Fri May 14 2021 20:36:07 GMT+0800 (China Standard Time)

Sounds like a reasonable fix.

Ted Ralphs · Answer 5 · Fri Oct 08 2021 01:14:25 GMT+0800 (China Standard Time)

Just to follow up, I don't think this ever happened, right?

Ted Ralphs · Answer 6 · Fri Oct 08 2021 01:16:38 GMT+0800 (China Standard Time)

Oops, sorry, looks like it was done in refactor (5b6a9a6), which is the right place for it. I'm going to close this for now, feel free to reopen if needed.