Menu

#406 setjmp/longjmp cause segmentation faults when used in a 64bit environment

v1.0 (example)
pending-fixed
nobody
None
5
2015-09-09
2014-06-25
No

https://github.com/antoniovazquezblanco/nspire_emu uses setjmp and longjmp (emu.c) and crashes when used in a 64bit windows environment because setjmp sets the stack register value to 0x10. Using __builtin_setjump avoids the problem because the stack register doesn't get messed (doesn't seem to call setjmp3 function of the C:\Windows\SysWOW64\msvcrt.dll library).

You can find attached a piece of gdb debugging of the program.

My version of mingw gcc:
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/4.9.0/lto-wrapper
Target: i686-w64-mingw32
Configured with: /build/mingw-w64-gcc/src/gcc-4.9.0/configure --prefix=/usr --libexecdir=/usr/lib --target=i686-w64-mingw32 --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-threads=posix --enable-fully-dynamic-string --enable-libstdcxx-time=yes --with-system-zlib --enable-cloog-backend=isl --disable-cloog-version-check --disable-isl-version-check --enable-lto --disable-dw2-exceptions --enable-libgomp --disable-multilib --enable-checking=release
Thread model: posix
gcc version 4.9.0 (GCC)

1 Attachments

Discussion

  • Ozkan Sezer

    Ozkan Sezer - 2015-03-19
    • status: open --> pending-fixed
     
  • Ozkan Sezer

    Ozkan Sezer - 2015-03-19

    This is possibly related to bug #465 which got fixed today. Changing status to pending-fixed.

     
  • kevinushey

    kevinushey - 2015-09-09

    I'm still observing this issue in a context roughly like this:

    // other set-up
    int status = 0;
    try {
        // C++ code that can throw
    } catch (...) {
        // populate some exception information
        status = 1;
    }
    
    if (status)
        // call C library in separate DLL that will longjmp
    

    The over-arching goal is to ensure C longjmps occur in a context where no C++ objects (ie, objects with non-trivial destructors) are on the stack.

    In fact, in my particular case, even attempting to directly call a setjmp / longjmp pair after that try-catch block fails (with a crash after a call to msvcrt!longjmp); however, calling __builtin_setjmp and __builtin_longjmp directly seems to work fine. However, the 'success' here seems to depend on stuff done within the try block...

    Unfortunately, I haven't yet been able to produce a minimally reproducible example (I have a reproducible example -- it's just not minimal), so some more investigation might be needed.

    In my case, I'm using a mingw64 build with SJLJ exceptions, win32 threads and gcc 4.9.3.


    Using built-in specs.
    COLLECT_GCC=C:\Rtools\GCC-49~1.3\bin\G__~1.EXE
    COLLECT_LTO_WRAPPER=C:/Rtools/GCC-49~1.3/bin/../libexec/gcc/i686-w64-mingw32/4.9.3/lto-wrapper.exe
    Target: i686-w64-mingw32
    Configured with: ../../../src/gcc-4.9.3/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32 --with-sysroot=/home/Jeroen/mingw-gcc-4.9.3/i686-493-win32-sjlj-rt_v3-s/mingw32 --with-gxx-include-dir=/mingw32/i686-w64-mingw32/include/c++ --enable-static --disable-shared --enable-targets=all --enable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --disable-isl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch-32=i686 --with-arch-64=nocona --with-tune-32=generic --with-tune-64=core2 --with-libiconv --with-system-zlib --with-gmp=/home/Jeroen/mingw-gcc-4.9.3/prerequisites/i686-w64-mingw32-static --with-mpfr=/home/Jeroen/mingw-gcc-4.9.3/prerequisites/i686-w64-mingw32-static --with-mpc=/home/Jeroen/mingw-gcc-4.9.3/prerequisites/i686-w64-mingw32-static --with-isl=/home/Jeroen/mingw-gcc-4.9.3/prerequisites/i686-w64-mingw32-static --with-cloog=/home/Jeroen/mingw-gcc-4.9.3/prerequisites/i686-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion='i686-win32-sjlj, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/home/Jeroen/mingw-gcc-4.9.3/i686-493-win32-sjlj-rt_v3-s/mingw32/opt/include -I/home/Jeroen/mingw-gcc-4.9.3/prerequisites/i686-zlib-static/include -I/home/Jeroen/mingw-gcc-4.9.3/prerequisites/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/home/Jeroen/mingw-gcc-4.9.3/i686-493-win32-sjlj-rt_v3-s/mingw32/opt/include -I/home/Jeroen/mingw-gcc-4.9.3/prerequisites/i686-zlib-static/include -I/home/Jeroen/mingw-gcc-4.9.3/prerequisites/i686-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/home/Jeroen/mingw-gcc-4.9.3/i686-493-win32-sjlj-rt_v3-s/mingw32/opt/lib -L/home/Jeroen/mingw-gcc-4.9.3/prerequisites/i686-zlib-static/lib -L/home/Jeroen/mingw-gcc-4.9.3/prerequisites/i686-w64-mingw32-static/lib -Wl,--large-address-aware'
    Thread model: win32
    gcc version 4.9.3 (i686-win32-sjlj, Built by MinGW-W64 project)

     

Log in to post a comment.

MongoDB Logo MongoDB