Understand disassemble for segfault on android

Nathan Hüsken nathan.huesken at posteo.de
Sun Jan 13 00:10:51 CET 2013


Hey,

I am still investigating the segfaults of the exectuable produced by ghc
to arm-linux-androideabi cross compiler.

I need help. Can someone tell me if my conclusions are correct?

The crash happens here:

Dump of assembler code for function stg_returnToStackTop:
   0x003f059c <+0>:	push	{r4, lr}
   0x003f05a0 <+4>:	sub	sp, sp, #16
   0x003f05a4 <+8>:	ldr	r1, [r0, #140]	; 0x8c
=> 0x003f05a8 <+12>:	ldr	r12, [r1, #12]
   0x003f05ac <+16>:	ldr	r1, [r12, #12]
   0x003f05b0 <+20>:	mov	r2, #0

Since it is in the begining of stg_returnToStackTop, it has to be
LOAD_THREAD_STATE();
I believe the code for this is produced by loadThreadState:

loadThreadState dflags tso stack = do
  catAGraphs [
        -- tso = CurrentTSO;
        mkAssign (CmmLocal tso) stgCurrentTSO,
        -- stack = tso->stackobj;
        mkAssign (CmmLocal stack) (CmmLoad (cmmOffset dflags (CmmReg
(CmmLocal tso)) (tso_stackobj dflags)) (bWord dflags)),
(...)

So I believe the instruction are mapped like this:

ldr	r1, [r0, #140]  <-> tso = CurrentTSO
ldr	r12, [r1, #12]  <-> stack = tso->stackobj

If that is true, the loaded tso pointer ([r0, #140]) must be wrong.

When I look at the backtrace at the moment of crash:

#0  0x003f0588 in stg_returnToStackTop ()
#1  0x003c2e74 in schedule (initialCapability=0x3f057c, task=0x52f350)
    at rts/Schedule.c:463
#2  0x003c2e74 in schedule (initialCapability=0x52f340, task=0x400a42f0)
    at rts/Schedule.c:463
#3  0x003c4cb0 in scheduleWaitThread (tso=0x401033c0, ret=0x0,
pcap=0xbe843b6c)
    at rts/Schedule.c:2351

There is a "tso" value passed to scheduleWaitThread (tso=0x401033c0).
Should be this is the same address, form where the tso is loaded in the
instruction:

ldr	r1, [r0, #140]  <-> tso = CurrentTSO

? If so, the value in r0 is way of.

info register
r0             0x3f057c	4130172
r1             0xe24dd010	-498216944


Are my conclusions so far correct, and I have to find out why r0 is
having the wrong value?

Thanks!
Nathan



More information about the Glasgow-haskell-users mailing list