[gccsdk] wesnoth crash when an exception is thrown
John.Tytgat at aaug.net
Fri Dec 5 15:25:12 PST 2008
In message <99b3a7f64f.Jo at hobbes.bass-software.com>
John Tytgat <John.Tytgat at aaug.net> wrote:
> In message <BLU141-W32A5326A4AFFA322B384C7F0560 at phx.gbl>
> alan buckley <alan_baa at hotmail.com> wrote:
> > [...]
> > I've tried creating a simple program that throws an exception and
> > that works OK. I also test going several functions down before
> > throwing the exception.
I just happen to have the same crash with gerb2tif program and I've fixed
this by changing to the SJLJ exception implementation in GCCSDK4 (like
in GCCSDK 3.4.6). Most probably the previous implementation wasn't well
working with our chunked stack implementation.
So rebuild GCCSDK from scratch (or at least libstc++ library, you need
to reconfigure it).
> The following is a shot in the dark and might be completely wrong: your
> stackdump indicates that this program is using pthreads. When you read
> above document it says that each thread in a C++ program has access to
> a separate object with type struct __cxa_eh_globals.
> I'm fairly sure that our UnixLib's pthread implementation is not giving
> each thread a separate struct __cx_eh_globals object on its own, nor we
> have any patches made to libstdc++ to be UnixLib pthread aware. So I'm
> missing how above requirement would be fulfilled.
> The __cxa_eh_globals object per thread is accessed via
> __cxa_get_globals(_fast) and this is implemented in
> libstdc++-v3/libsupc++/eh_globals.cc, actually there are multiple
> implementations: TLS, GTHREADS and single thread. I guess we're currently
> using the single thread implementation and that using exceptions in
> a multithreaded program simply does not work (reliably).
Most probably this was an additional problem as well. I believe SJLJ
exception implementation is thread aware.
John Tytgat, in his comfy chair at home BASS
John.Tytgat at aaug.net ARM powered, RISC OS driven
More information about the gcc