In that case you might be in the same situation I was in. Our third-party libs used Boost.Thread statically linked. It took me quite a while before I realized
Hi Neil, many thx for your hints, it brought me on the right way. this was a possible cause of the problem. I could see a completely messed-up context when catching the exceptions with the debugger. Meanwhile I found out, that the third party libs didn't use boost, but heavily used win-threads, with thread pooling mechanisms. In our huge structure, I also found some code, what implements a kind of watchdog on a given thread id. There was looked for a somehow specified timeout and if the timeout became active the thread was directly terminated with the WINAPI function 'TerminateThread(...)', so boost thread can not recognize this, and so I have had the situation, that the thread sometimes crash in the sleep function or leave mutexes in an inconsistent state. So by the way, have you an example how is the right way to terminate a boost thread? I haven't understood the 'interuptable' things in the documentation.
Sorry for missing this information out previously, I am having issues with Trac and could not find the thread of discussion with Anthony. I have finally found the threads of discussion and the changes were merged into Boost 1.47.
So I believe it has nothing to do with the fix, but if you can found this communication with Anthony (perhaps he read this ;-), I am very interessted in this disscussion, because we have some more complicated problems in the multi threaded area, what can at least explained simalar to the ODR violation fix, if we know at least the circumstances of this fix.
Can you try Boost 1.47? If this does not work, then we can explore alternative approaches.
I have done a test with 1.49, but I can not switch to it completly, because of other issues with the filesystem library v3 at the moment, but this is another point. best regards Arno