#704 MinGW 3.4.2 segfaults in throw()

Known_bugs
closed-fixed
gcc (462)
2005-02-09
2005-01-13
Nach M. S.
No

A simple C++ file such as this:
int main() { try { throw(5); } catch (...) {} return(0); }
Causes a segmentation fault.

GDB backtrace shows this:
__cxa_throw ()
As being the problem.

Discussion

  • Danny Smith

    Danny Smith - 2005-01-14

    Logged In: YES
    user_id=11494

    I can't reproduce on NT4(SP5) or XP.
    Please provide more details including output of g++ -v with
    your testcase.
    Danny

     
  • Nach M. S.

    Nach M. S. - 2005-01-14

    Logged In: YES
    user_id=695796

    Reading specs from /usr/lib/gcc/i586-mingw32msvc/3.4.2/specs
    Configured with:
    /home/ron/devel/debian/mingw32/mingw32-3.4.2.20040916.1/build_dir/src/gcc-3.4.2-20040916-1/configure
    -v --prefix=/usr --target=i586-mingw32msvc
    --enable-languages=c,c++ --enable-threads --disable-multilib
    --enable-version-specific-runtime-libs
    Thread model: win32
    gcc version 3.4.2 (mingw-special)

    The compiled binary crashes on WinXP and on WINE.

     
  • Danny Smith

    Danny Smith - 2005-01-14

    Logged In: YES
    user_id=11494

    Please provide output of g++ -v _with your testcase_, eg
    g++ -v foo.cpp. I'm wondering if you are picking up wrong
    version of libstc++.a

    You should probably report this to the org that distributed the
    binaries. The binaries distributed at mingw.org handle your
    testcase ok.

    Danny

     
  • Nach M. S.

    Nach M. S. - 2005-01-14

    Logged In: YES
    user_id=695796

    As you requested:
    Reading specs from /usr/lib/gcc/i586-mingw32msvc/3.4.2/specs
    Configured with:
    /home/ron/devel/debian/mingw32/mingw32-3.4.2.20040916.1/build_dir/src/gcc-3.4.2-20040916-1/configure
    -v --prefix=/usr --target=i586-mingw32msvc
    --enable-languages=c,c++ --enable-threads --disable-multilib
    --enable-version-specific-runtime-libs
    Thread model: win32
    gcc version 3.4.2 (mingw-special)
    /usr/libexec/gcc/i586-mingw32msvc/3.4.2/cc1plus -quiet -v
    filetest.cpp -quiet -dumpbase filetest.cpp -mtune=pentium
    -auxbase filetest -version -o /tmp/ccGzAtKT.s
    ignoring nonexistent directory
    "/usr/lib/gcc/i586-mingw32msvc/3.4.2/../../../../i586-mingw32msvc/sys-include"
    #include "..." search starts here:
    #include <...> search starts here:
    /usr/lib/gcc/i586-mingw32msvc/3.4.2/include/c++
    /usr/lib/gcc/i586-mingw32msvc/3.4.2/include/c++/i586-mingw32msvc
    /usr/lib/gcc/i586-mingw32msvc/3.4.2/include/c++/backward
    /usr/lib/gcc/i586-mingw32msvc/3.4.2/include
    /usr/lib/gcc/i586-mingw32msvc/3.4.2/../../../../i586-mingw32msvc/include
    End of search list.
    GNU C++ version 3.4.2 (mingw-special) (i586-mingw32msvc)
    compiled by GNU C version 3.3.5 (Debian 1:3.3.5-2).
    GGC heuristics: --param ggc-min-expand=47 --param
    ggc-min-heapsize=32148
    /usr/lib/gcc/i586-mingw32msvc/3.4.2/../../../../i586-mingw32msvc/bin/as
    -o /tmp/ccJ63Aas.o /tmp/ccGzAtKT.s
    /usr/libexec/gcc/i586-mingw32msvc/3.4.2/collect2 -Bdynamic
    /usr/lib/gcc/i586-mingw32msvc/3.4.2/../../../../i586-mingw32msvc/lib/crt2.o
    /usr/lib/gcc/i586-mingw32msvc/3.4.2/crtbegin.o
    -L/usr/lib/gcc/i586-mingw32msvc/3.4.2
    -L/usr/lib/gcc/i586-mingw32msvc/3.4.2
    -L/usr/lib/gcc/i586-mingw32msvc/3.4.2/../../../../i586-mingw32msvc/lib/tmp/ccJ63Aas.o
    -lstdc++ -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt
    -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc
    -lmoldname -lmingwex -lmsvcrt
    /usr/lib/gcc/i586-mingw32msvc/3.4.2/crtend.o

    Yes I use the binaries you distribute at mingw.org on
    Windows, but I don't have that option when I want to cross
    compile from Linux ;)

     
  • Nach M. S.

    Nach M. S. - 2005-01-14

    Logged In: YES
    user_id=695796

    Oh and I don't think I was clear before. MinGW itself
    doesn't segmentation fault. The binary it produces does.

    Code which doesn't use exception handling works fine though.

     
  • Danny Smith

    Danny Smith - 2005-01-14

    Logged In: YES
    user_id=11494

    Thanks for feedback.

    The problem may be with Dwarf2 unwind info. Look at
    libgcc.a for symbol _Unwind_SjLj_Register. If not there, then
    the Debian distro needs to be reconfigured with --enabled-sjlj-
    exceptions to match the mingw.org distro. Dwarf2 can be
    made to work with gcc-3.4.4 but I haven't tried with 3.4.2
    Danny

     
  • Nach M. S.

    Nach M. S. - 2005-01-14

    Logged In: YES
    user_id=695796

    I could not find that symbol in libgcc.a, I already reported
    the problem to Debian:
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=290425
    Now I'll follow up with the fix.

    Thanks for your help. I just hope the Debian team will be as
    prompt with fixing the problem.

     
  • Ron

    Ron - 2005-01-14

    Logged In: YES
    user_id=78887

    Thanks Danny,

    I generally try to keep the Debian specific options as light
    as possible, relying on you guys to patch in the right
    defaults most of the time.
    (which is working better and better, the last couple I have
    been able to 'package' just by dropping in the new tarball
    and pressing 'go'... so
    things are finally settling into a nice consistency.)

    I'm currently using:
    --enable-threads
    --disable-multilib
    --enable-version-specific-runtime-libs

    I can add the sjlj switch too if that is the right thing to
    do though.
    Are there any others I should know about/use with 3.4?

    cheers,
    Ron

     
  • Danny Smith

    Danny Smith - 2005-01-14

    Logged In: YES
    user_id=11494

    I'm not sure thatl lack of --enable-sjlj-exceptions is indeed
    the cause of the problem. The only way to tell would be to
    compare testsuite results. Regardless, it would be nice C++
    objects compiled with debian distro were ABI compatible with
    objects produced by mingw.org compiler.

    I don't know of any other config switches that need to be
    added.

    Danny

     
  • Danny Smith

    Danny Smith - 2005-01-31

    Logged In: YES
    user_id=11494

    I'm closing as it doesn't appear to be a problem with
    mingw.org distro. Re-open if you think that it can be fixed by
    mingw.org.

    Danny

     
  • Danny Smith

    Danny Smith - 2005-01-31
    • status: open --> closed-works-for-me
     
  • Ron

    Ron - 2005-01-31

    Logged In: YES
    user_id=78887

    Thanks Danny, I do have a report that adding this switch
    seems to fix
    the incompatibility, so I'll add it to the packages. Is
    this something I
    need to keep an eye on in the short to mid term or is this
    config likely
    to remain the default for the forseeable future?

    The mingw list seems to have first started bouncing my
    posts, then
    unsubbed me as well so I haven't been following things as
    closely
    as I might, but I certainly would like to maintain ABI
    compatibility
    with other distributors nonetheless.

    cheers,
    Ron

     
  • Danny Smith

    Danny Smith - 2005-01-31

    Logged In: YES
    user_id=11494

    ronl wrote:
    "Is this something I need to keep an eye on in the short to
    mid term or is this config likely to remain the default for the
    forseeable future?"

    I was hoping to get Dwarf2 unwind support into gcc-4.0.0 but
    was too little, too late. With some help, Inshallah, the main
    holdup (catching exceptions in w32api callbacks) may be
    solved for 4.1. So keep bugging me and I'll keep you
    informed when that happens. But the next release (3.4.4) will
    still be --enable-sjlj-exceptions.

    ronl also wrote:
    "The mingw list seems to have first started bouncing my
    posts, then unsubbed me as well"

    Gosh, sometimes I wish the latter would happen to me. Any
    clues why it happened?

    Danny

     
  • Ron

    Ron - 2005-02-07

    Logged In: YES
    user_id=78887

    :-) IIRC my posts started bouncing because the address I
    was subbed
    with had not been the address in my reply-to for a while --
    well before
    the anti-spam measures were introduced, but they got me just
    the same.
    I'm guessing some badly timed bounces got me unsubbed, but
    I'm not
    too sure what really happened there. And I needed a bit of
    a bandwidth
    holiday myself for a while. SA surely eats more of my cpu
    cycles some
    days than gcc does now. :/

    Anyway, new packages have been uploaded now that shouldn't have
    this problem anymore, but I do still have 2 open issues
    that would
    seem fairly straight forward to fix:

    http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mingw32-runtime

    These appear to still affect the current release, so I
    assume they
    weren't raised here before that. Both appear to be simple
    header
    glitches, so it seems overkill to open a new item here. And
    this
    web form is _not_ vim, so feel free to follow this up in the
    debian
    bts or via straight email if need be...

    cheers,
    Ron

     
  • Nach M. S.

    Nach M. S. - 2005-02-07

    Logged In: YES
    user_id=695796

    Ron:

    Thanks for fixing the problem.

    Getting some of my software beta tested this past month was
    annoying when I needed to boot another machine to compile my
    software's most popular port.

     
  • Nach M. S.

    Nach M. S. - 2005-02-08

    Logged In: YES
    user_id=695796

    Ron:

    Sorry to bother you, but I ran into a bug with your new build.
    Try to compile this file:
    http://cvs.sourceforge.net/viewcvs.py/zsnes/zsnes/src/win/winlink.cpp?rev=1.280&view=markup

    With this line: i586-mingw32msvc-g++ -O0 -masm=intel -o
    winlink.o -c winlink.cpp

    And I get a bunch of errors like this:
    /tmp/ccAfHweD.s: Assembler messages:
    /tmp/ccAfHweD.s:7217: Error: suffix or operands invalid for
    `fnstcw'
    /tmp/ccAfHweD.s:7221: Error: suffix or operands invalid for
    `fldcw'
    /tmp/ccAfHweD.s:7223: Error: suffix or operands invalid for
    `fldcw'
    /tmp/ccAfHweD.s:7257: Error: suffix or operands invalid for
    `fnstcw'
    /tmp/ccAfHweD.s:7261: Error: suffix or operands invalid for
    `fldcw'
    /tmp/ccAfHweD.s:7263: Error: suffix or operands invalid for
    `fldcw'
    /tmp/ccAfHweD.s:7302: Error: suffix or operands invalid for
    `fnstcw'

    Previous builds from you, and official MinGW builds do not
    bomb out like this.

     
  • Danny Smith

    Danny Smith - 2005-02-08

    Logged In: YES
    user_id=11494

    n-a-c-h$ wrote:
    And I get a bunch of errors like this:
    /tmp/ccAfHweD.s: Assembler messages:
    /tmp/ccAfHweD.s:7217: Error: suffix or operands invalid for
    `fnstcw'

    This is a different bug.

    I suspect this is from inline asm in math.h. I thought that bug
    was fixed with latest binutils RC from mingw. What does as --
    version report.

    If as version >= 2.15.94 20050118 please open a new bug
    report. Otherwise try a newer binutils before opening new
    bug.

    Danny

     
  • Nach M. S.

    Nach M. S. - 2005-02-08

    Logged In: YES
    user_id=695796

    Yes this is a different bug, but it was directed at Ron who
    fixed the reported bug but introduced a new one somehow in
    the proccess.

    Do a --version on which executable?

     
  • Ron

    Ron - 2005-02-08

    Logged In: YES
    user_id=78887

    I don't have much to add different to what Danny said.
    I ran a test build of wx before uploading without problems
    and its usually reasonably good at finding the obvious ones.

    If you didn't upgrade the mingw32-binutils (and -runtime)
    package(s), please try that, I have not tested this compiler
    at all with earlier binutils. If you already did so, then
    please
    report this as Danny suggests as you do have the new
    candidate binutils.

    i586-mingw32msvc-as, or the mingw32-binutils package version
    will give you the information requested explicitly.

     
  • Danny Smith

    Danny Smith - 2005-02-08

    Logged In: YES
    user_id=11494

    What does "as --version" report?
    Never mind, I'm able to reproduce with as 2.15.94 with this
    testcase:

    void foo()
    {
    unsigned short _cw;
    __asm__ ("fnstcw %0;": "=m" (_cw));
    __asm__ ("fldcw %0;" : : "m" (_cw));
    }

     
  • Nach M. S.

    Nach M. S. - 2005-02-08

    Logged In: YES
    user_id=695796

    GNU assembler 2.15.94 20050118 is what I have.

    Ron: I did a dist-upgrade in unstable, so I have the latest
    stuff you put out.

     
  • Nach M. S.

    Nach M. S. - 2005-02-08

    Logged In: YES
    user_id=695796

    GNU assembler 2.15.94 20050118 is what I have.

    Ron: I did a dist-upgrade in unstable, so I have the latest
    stuff you put out.

     
  • Danny Smith

    Danny Smith - 2005-02-09
    • status: closed-works-for-me --> closed-fixed
     
  • Danny Smith

    Danny Smith - 2005-02-09

    Logged In: YES
    user_id=11494

    The intel syntax bug was generic to ix86. It has been
    reported to binutils bugzilla and a fix has ben committed to
    binutils CVS.

    Now can we really close this ticket....

    Danny

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks