[gccsdk] Wesnoth latest crash

[Lee Noar]

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.