[gccsdk] wesnoth crash when an exception is thrown

John Tytgat John.Tytgat at aaug.net
Thu Oct 30 18:40:20 PDT 2008

In message <BLU141-W32A5326A4AFFA322B384C7F0560 at phx.gbl>
          alan buckley <alan_baa at hotmail.com> wrote:

> wesnoth now builds and runs - thanks for the
> previous fixes however it will now crash at the
> end of a scenario.
> It appears to be when it throws an exception.
> The error details are:
> Fatal signal received: Segmentation fault
> Stack backtrace:
> Running thread 0x7d7d14
>   (  bbff00) pc:   61c7f8 lr:   61cd4c sp:   bbff04  __write_backtrace()
>   (  bbffa0) pc:   61c8e0 lr:   61d7cc sp:   bbffa4  __unixlib_raise_signal()
>   (  bbffb0) pc:   61d6d0 lr:   5f0d08 sp:   bb1bcc  __h_cback()
>   Register dump at 00bbffb4:
>     a1:   bb94a8 a2:        0 a3:  4a035c4 a4:        0
>     v1:        0 v2:        0 v3:    4702f v4:    471a0
>     v5:   668074 v6:        2 sl:   bad188 fp:   bb1c2c
>     ip:        0 sp:   bb1bcc lr:   5f0d08 pc:   5fc1f8
>     cpsr: 60000010
>   005fc1e4 : ind_ : 5f646e69 : SWIPL   &646E69
>   005fc1e8 : SetG : 47746553 : Undefined instruction
>   005fc1ec : R... : 00000052 : ANDEQ   R0,R0,R2,ASR R0
>   005fc1f0 : ...ÿ : ff000010 : Undefined instruction
>   005fc1f4 : .1ç : e7903101 : LDR     R3,[R0,R1,LSL #2]
>   005fc1f8 : . Č : e5832000 : STR     R2,[R3,#0]
>   005fc1fc : .ð á : e1a0f00e : MOV     PC,R14
>   005fc200 : _Unw : 776e555f : Undefined instruction
>   005fc204 : ind_ : 5f646e69 : SWIPL   &646E69
>   (  bb1c2c) pc:   5f0a98 lr:   5fdbf8 sp:   bb1c30  __gxx_personality_v0()
>   (  bb92fc) pc:   5fdbb8 lr:   62af04 sp:   bb9300  ^_Unwind_RaiseException_Phase2()
>   (  bb99ac) pc:   5fe2bc lr:   5f1138 sp:   bb99b0  _Unwind_RaiseException()
>   (  bb99c4) pc:   5f10e8 lr:    47030 sp:   bb99c8  __cxa_throw()

In case someone feels curious about how exceptions are implemented and
want to investigation this, the following document
<URL:http://www.codesourcery.com/public/cxx-abi/abi-eh.html> will help
understanding what this is all about.

> [...]
> 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.

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).

> Anybody have any clues on what is going wrong?

Hope above info might help a bit.  I'm away the coming month so I won't
be able to look into this at all.  Any volunteers ?

John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven

More information about the gcc mailing list