Peter Naulls wrote:
I'm seeing a crash shortly after threading begins using a shared library version of Firefox. Of course, there are lots of things involved including no less than 83 separate libraries. The crash isn't entirely consistent, proably because sometimes it gets a valid enough value to try and continue. But this is reasonably repeatable:Fatal signal received: Segmentation fault Stack backtrace: Running thread 0x39cfc ( 15c7ef8) pc: 5c748c3c lr: 5c7491e8 sp: 15c7efc ?() ( 15c7fa0) pc: 5c748d40 lr: 5c749eb4 sp: 15c7fa4 ?() ( 15c7fb0) pc: 5c749d60 lr: 5dc6737c sp: 15c5f94 __h_cback() Register dump at 015c7fb4: a1: 1 a2: 8000 a3: 6540285 a4: 0 v1: 1d9ff0 v2: 15c6250 v3: 20a028 v4: 1c77dc v5: 57d04bb8 v6: 1d9be0 sl: 15c4200 fp: 15c5fb4 ip: 36178 sp: 15c5f94 lr: 5dc6737c pc: 5c6e495c cpsr: 20000093 5c6e4948 : llba : 61626c6c : Undefined instruction 5c6e494c : ck.. : 00006b63 : ANDEQ R6,R0,R3,ROR #22 5c6e4950 : ...ÿ : ff000014 : Undefined instruction 5c6e4954 : .!Ÿå : e59f211c : LDR R2,&5C6E4A78 5c6e4958 : . —ç : e7972002 : LDR R2,[R7,R2] 5c6e495c : <.’å : e592003c : LDR R0,[R2,#60] 5c6e4960 : ..0ã : e3300000 : TEQ R0,#0 5c6e4964 : @.’. : 05920040 : LDREQ R0,[R2,#64] 5c6e4968 : ..0. : 03300000 : TEQEQ R0,#0 The backtrace itself varies, but is code that is currently running. The code above is of course from __pthread_callback in UnixLib. I haven't actually tried any other pthread code with shared libraries, so I don't know if this is unique or not to Firefox.
I suspect that r7 does not contain UnixLib's GOT pointer as it should and that is why you get a bogus value in r2 which causes the seg fault. The change I've just committed (r3519) should fix it.
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
