[gccsdk] wesnoth crash when an exception is thrown
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