Re: [gccsdk] Wesnoth latest crash

Fri, 13 Feb 2009 13:39:20 -0800 

alan buckley wrote:

I rebuilt wesnoth again just before christmas
and have only just managed to get time to
analyse the latest crash.
This occurs in the same place as the last one, 
but I believe the details are different so John's
modification did do something.


[snip]


  Register dump at 00bbffb4:
    a1: fffffffc a2: ffffffff a3:   bb2410 a4:        1
    v1:   bb3290 v2:   bb0224 v3:   8fca9c v4:        1
    v5:   903944 v6:   baaf8c sl:   bb01a0 fp:   bb0280
    ip:   bb6fa8 sp:   bb0200 lr:   537758 pc:   7c29b4
    cpsr:       10


[snip]


Code leading up to the location of the crash:

007C2988 : 394E5A5F : _ZN9 : STMCCDB R14,{R0-R4,R6,R9,R11,R12,R14}^
007C298C : 6E675F5F : __gn : MCRVS   CP15,3,R5,C7,C15,2  ; ARMv4 Cache 
Operations
007C2990 : 78635F75 : u_cx : STMVCDA R3!,{R0,R2,R4-R6,R8-R12,R14}^  ; *** ! and 
^
007C2994 : 5F383178 : x18_ : SWIPL   &383178
007C2998 : 6378655F : _exc : Undefined instruction
007C299C : 676E6168 : hang : STRVSB  R6,[R14,-R8,ROR #2]!
007C29A0 : 6E615F65 : e_an : CDPVS   CP15,6,C5,C1,C5,3
007C29A4 : 64615F64 : d_ad : STRVSBT R5,[R1],#-3940
007C29A8 : 56504564 : dEPV : LDRPLB  R4,[R0],-R4,ROR #10
007C29AC : 00006969 : ii.. : ANDEQ   R6,R0,R9,ROR #18
007C29B0 : FF000028 : (..ÿ : Undefined instruction
007C29B4 : E5902000 : . �å : LDR     R2,[R0,#0]   <--- Calling here
007C29B8 : E5903000 : .0�å : LDR     R3,[R0,#0]
007C29BC : E0833001 : .0Ĉ : ADD     R3,R3,R1
007C29C0 : E5803000 : .0ی : STR     R3,[R0,#0]

 
terrain_label::clear() called from terrain_label::~terrain_label

before the crash. I'm including it for completeness, but I'm not
sure if it is relevant.

 
005362CC : 314E5A5F : _ZN1 : Undefined instruction

005362D0 : 72657433 : 3ter : RSBVC   R7,R5,#&33000000
005362D4 : 6E696172 : rain : MCRVS   CP1,3,R6,C9,C2,3
005362D8 : 62616C5F : _lab : RSBVS   R6,R1,#&5F00
005362DC : 63356C65 : el5c : Undefined instruction
005362E0 : 7261656C : lear : RSBVC   R6,R1,#&1B000000
005362E4 : 00007645 : Ev.. : ANDEQ   R7,R0,R5,ASR #12
005362E8 : FF00001C : ...ÿ : Undefined instruction
005362EC : E1A0C00D : .À á : MOV     R12,R13
005362F0 : E92DD810 : .Ø-é : STMDB   R13!,{R4,R11,R12,R14,PC}
005362F4 : E24CB004 : .°Lâ : SUB     R11,R12,#4
005362F8 : E15D000A : ..]á : CMP     R13,R10
005362FC : BB0B1C44 : D..» : BLLT    &007FD414
00536300 : E5903000 : .0�å : LDR     R3,[R0,#0]
00536304 : E1A04000 : .@ á : MOV     R4,R0
00536308 : E2530000 : ..Sâ : SUBS    R0,R3,#0
0053630C : 091BA810 : .¨.. : LDMEQDB R11,{R4,R11,R13,PC}
00536310 : EBFF712A : *qÿë : BL      &005127C0
00536314 : E3A03000 : .0 ã : MOV     R3,#0
00536318 : E5843000 : .0„å : STR     R3,[R4,#0]

 
 
This looks like the function name from before the code

that crashes.

 
_ZN9__gnu_cxx18__exchange_and_addEPVii


Does anybody know what the problem could be and how to
fix it?



Not quite no, but I can perhaps add a few more details. I'm fairly 
certain that terrain_label::clear() is calling the destructor of a 
std::string which in turn is calling __gnu_cxx::exchange_and_add(). The 
first argument to exchange_and_add should be a memory location, but here 
it is -4 which is what causes the seg fault. The second arg (-1) is 
correct (see libstdc++-v3/include/bits.basic_string.h 
basic_string::_M_dispose()).



A quick google for the exchange_and_add function shows that seg faults 
can also occur on other platforms so it may not be specific to RISC OS 
(not that that is much comfort :-/)



The crash doesn't appear to be related to exceptions, and although the 
source for exchange_and_add() refers to mutex locks, the code above 
doesn't use them. Perhaps it should, but IIRC, a thread swap only occurs 
when returning from OS code such as a SWI call, so this code shouldn't 
need to be made thread safe.


I'll see if I can dig a bit deeper.

Lee.


_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK





















					Reply via email to