From: Viatcheslav.Sysoltsev@h-d-gmbh.de Date: Thu, 17 Feb 2011 09:42:53 +0100 Subject: Re: [Boost-users] [Thread] Interrupting a thread causes a segmentation fault

I believe the test programm is all right, it works well with boost 1.36 and 1.45 on linux with gcc 4.3.2 with both dynamic and static boost linkage. Check out the stack trace at the moment of failure, it shall give good insight into kind of problem.

-- Slava

I ran the debugger and took a look at the output at the point of the fault. Unfortunately, I didn't find it particularly enlightening, although it seems clear that the fault is occurring when the thread_interrupted exception is thrown by the Boost Thread library. In case it might be useful, I've included the information from the debugger below, as well as an excerpt from thread.cpp containing the function in which the fault occurs (to save anyone reading this the time of going to check the source). Any suggestions as to what might be the problem here would be appreciated; I also should note that I'm using Windows XP, so it may be an issue with the Windows API since the program apparently runs fine on Linux. Thanks, William CALL STACK ============================================================================= #0 00000000    0x00406410 in __cxa_throw() (??:??) #1 00403070    boost::this_thread::interruption_point() (libs\thread\src\win32\thread.cpp:495) #2 00401359    testingThread() (C:\Documents and Settings\WFrane\My Documents\C++ code\boost thread interrupt test\boost_thread_interrupt_test\main.cpp:12) #3 00422666    boost::detail::thread_databoost::this_thread::interruption_enabled() 00403018    test   %al,%al 0040301A    je     0x403029 boost::this_thread::interruption_point()+28 0040301C    call   0x403095 boost::this_thread::interruption_requested() 00403021    test   %al,%al 00403023    je     0x403029 boost::this_thread::interruption_point()+28 00403025    mov    $0x1,%al 00403027    jmp    0x40302b boost::this_thread::interruption_point()+30 00403029    mov    $0x0,%al 0040302B    test   %al,%al 0040302D    je     0x403070 boost::this_thread::interruption_point()+99 0040302F    call   0x40184c 00403034    add    $0xc,%eax 00403037    mov    %eax,(%esp) 0040303A    call   0x4280dc 0040303F    mov    %eax,(%esp) 00403042    mov    0x488298,%eax 00403047    call   *%eax 00403049    sub    $0x4,%esp 0040304C    movl   $0x1,(%esp) 00403053    call   0x405e8c <__cxa_allocate_exception> 00403058    movl   $0x0,0x8(%esp) 00403060    movl   $0x47ccec,0x4(%esp) 00403068    mov    %eax,(%esp) 0040306B    call   0x40640c <__cxa_throw> 00403070    leave 00403071    ret ============================================================================= SOURCE FOR boost::this_thread::interruption_point() (lines 490-497 of boost\boost_1_45_0\libs\thread\src\win32\thread.cpp) ============================================================================= void interruption_point()         {             if(interruption_enabled() && interruption_requested())             {                 detail::win32::ResetEvent(get_current_thread_data()->interruption_handle);                 throw thread_interrupted();             }         } =============================================================================

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

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

Hello Slava, I'm linking all the Boost libraries statically, so I don't think DLL issues are the cause in this case (although I too have seen reports of Boost Thread functionality not working correctly when dynamically linking using MinGW). I'll upgrade MinGW and see if that resolves the issue. Regards, William

Are you sure you're not getting more than one boost library in your executable then?

I've managed to do that before (with MSVC, not MinGW), and those bugs can be a PITA to find.

Do you mean more than one version of the same library, e.g., debug and release? If so, I'm fairly certain that's not happening (the build commands used are in my first post, and only one version of the Boost Thread library is linked). However, if I've misunderstood you, please let me know; I did have to manually define BOOST_THREAD_USE_LIB in my own program to use static linking for the Thread library (see https://svn.boost.org/trac/boost/ticket/4614), which seemed a bit off, so it's possible there's something going wrong there (although I'd expect it to affect the other aspects of the Thread library as well). William

I don't think it's a boost problem. As a data point, it worked fine for me: $ g++ -static -I $BH/include/boost-1_45 -L $BH/lib crashtest.cpp \ -lboost_thread-mgw45-mt-1_45 $ ./a.exe MAIN: Created thread; sleeping now. MAIN: About to interrupt thread. MAIN: Sent interrupt to thread. THREAD: Ending. MAIN: Thread has ended. I am using MinGW 4.5.0 on WinXP: $ g++ -v Using built-in specs. COLLECT_GCC=c:\MinGW\bin\g++.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.5.0/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.5.0 (GCC) Andy On 2/17/2011 3:39 PM, W Frane wrote:

...

Perhaps you need -mthreads?

- Marsh

Thank you for the suggestion, but unfortunately adding -mthreads did not resolve the issue. (Threaded programs without interrupts work fine, incidentally; it appears to be the interrupts that are causing the problem, not multithreading in general.)

William

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users