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.
Hi William, Maybe exception handling does not work well across dll boundary? I never used minGW, but internet search showed there were/are some difficulties with it. Is it feasible to upgrade to 4.5 compiler, since Andy says it works for him? -- Slava