Are you sure your compiler supports exception handling in your setup? I'd try some simple exception hanlding program with the same compiler switches. If you set breakpoint on 0040306B, does __cxa_throw resolve to 00000000 or you get there from inside __cxa_throw? If first, there something wrong with linking or compiler setup; if latter, something wrong with EH structures in generated code (either in boost or in your test program). Have you build boost yourelf? If not, maybe it is worthy to try to rebuild boost with the same compiler and try it. Make sure -fexceptions or whatevers it must be for mingw is used in build process.
-- Slava
I've been compiling my test program with -fexceptions but I didn't originally compile the Boost libraries with that option. In light of this discussion, I recompiled the Boost libraries with -fexceptions (using the command .\bjam toolset=gcc cxxflags="-fexceptions" -a) and recompiled my test program. Unfortunately, the problem still persists. I added a breakpoint to 00403077 (after I recompiled my program after recompiling the Boost libraries as described above, 00403077 corresponded to the same line in the disassembly of boost::this_thread::interruption_point that 0040306B originally did) and it resolved to 0x2063f. I also added a breakpoint to __cxa_throw (in a separate debugging session) and it resolved to 0x40641c. In this second case (with the breakpoint at __cxa_throw), I stepped forward instruction by instruction once the breakpoint was reached and established that the segmentation fault occurs several instructions into __cxa_throw itself. I also ran a quick test program (modified from the test program I included in my original post) to check that the exception handling in MinGW is working. I altered the code so that the interrupt is removed and a std::exception is thrown by the thread function after 10 iterations of the while loop. The std::exception was caught without incident by the catch(...) block, so exception handling seems to work fine with regular exceptions. William