Building on android - compiled program segfaults

[Nathan Hüsken]

Ok, $r0 + 140 is loaded into $r1.
The value at the address ($r0+140 = 0x3F06A0) at the moment of crash is
the same as at the moment main is entered. And a watch on this address
reveals, that it is not touched.


On 01/11/2013 04:09 PM, Nathan Hüsken wrote:
> The disassembly at the moment of segfault looks like this:
> 
> 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
>    0x003f05b4 <+24>:	str	r2, [r0, #156]	; 0x9c
>    0x003f05b8 <+28>:	ldr	r4, [r0, #148]	; 0x94
>    0x003f05bc <+32>:	ldm	r4, {r2, lr}
>    0x003f05c0 <+36>:	ldr	r4, [r4, #28]
>    0x003f05c4 <+40>:	add	r2, r2, r4, lsl #12
>    0x003f05c8 <+44>:	sub	r2, r2, #1
>    0x003f05cc <+48>:	str	r2, [r0, #132]	; 0x84
>    0x003f05d0 <+52>:	subs	r2, lr, #4
> 
> If I see this correctly, r12 is loaded with the value at ($r1+12)
> The value of $r1 is:
> 
> r1             0xe24dd010	-498216944
> 
> which seems way out of bounds (if I look at the values of the other
> registers).
> The value of r1 comes from ($r0+140) in the instruction above.
> But where is this value written?
> 
> I am sorry that I am so helpless. Some Idea where I could go from here?
> 
> On 01/11/2013 03:36 PM, Simon Marlow wrote:
>> On 11/01/13 13:47, Nathan Hüsken wrote:
>>> I just find out how to get in usefull backtrace with android ndk
>>> (unfortantly I am also new to the ndk).
>>>
>>> Now I get:
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x003f05a8 in stg_returnToStackTop ()
>>> (gdb) bt
>>> #0  0x003f05a8 in stg_returnToStackTop ()
>>> #1  0x003c2e74 in schedule (initialCapability=0x3f059c, task=0x530350)
>>>      at rts/Schedule.c:463
>>> #2  0x003c2e74 in schedule (initialCapability=0x530340, task=0x400a42f0)
>>>      at rts/Schedule.c:463
>>> #3  0x003c4c50 in scheduleWaitThread (tso=0x401033c0, ret=0x0,
>>> pcap=0xbe89ab6c)
>>>      at rts/Schedule.c:2345
>>> #4  0x00408544 in rts_evalLazyIO (cap=0xbe89ab6c, p=0x50a020, ret=0x0)
>>>      at rts/RtsAPI.c:499
>>> #5  0x003c08c8 in real_main () at rts/RtsMain.c:68
>>> #6  0x003c0a54 in hs_main (argc=1, argv=0xbe89abf4,
>>> main_closure=0x50a020,
>>>      rts_config=...) at rts/RtsMain.c:123
>>> #7  0x0000a23c in main ()
>>>
>>> stg_returnToStackTop is defined in rts/StgStartup.cmm (a c-- file).
>>>
>>> I would guess that
>>>
>>> jump %ENTRY_CODE(Sp(0)) [];
>>>
>>> could be the problem. Since p8 $r13 gives me
>>>
>>> 0xbef00a74:    0x0
>>> (...)
>>>
>>> Sp(0) would be 0x0, correct?
>>
>> It's dying pretty quickly after entering Haskell: stg_returnToStackTop
>> is the first bit of code to execute on the Haskell side.  You should be
>> able to disassemble that function and see whether it makes sense, and/or
>> step through it to see where things go wrong.  It does look like $r13 is
>> not pointing to stack data for some reason.
>>
>> Cheers,
>>     Simon
>>
>>
>>> On 01/11/2013 02:16 PM, Simon Marlow wrote:
>>>> On 11/01/13 11:36, Nathan Hüsken wrote:
>>>>> Hi,
>>>>>
>>>>> I was succesfull in building ghc (pulled from git) to compile for
>>>>> arm-linux-androideabi!
>>>>>
>>>>> Now using "inplace/bin/ghc-stage1 -dcore-lint -debug" I compiler this
>>>>> Main.hs:
>>>>>
>>>>> main = putStrLn "Hello, World"
>>>>>
>>>>> I get an executable, which I can run on my android device. Unfortantly
>>>>> it segfaults.
>>>>>
>>>>> Running it with ./Main +RTS -DS gives:
>>>>>
>>>>> cap 0: initialised
>>>>>
>>>>> Now I am trying to debug this in gdb. When I try to display the stack
>>>>> (which should be in r13 on arm of I understand correctly, I get);
>>>>
>>>> First establish whether the crash is in C or Haskell: what does 'bt'
>>>> tell you in gdb?
>>>>
>>>> Cheers,
>>>>      Simon
>>>>
>>>>
>>>>> (gdb) p8 $r13
>>>>> 0xbef00a74:    0x0
>>>>> 0xbef00a70:    0x0
>>>>> 0xbef00a6c:    0x3c2e74
>>>>> 0xbef00a68:    0x530350
>>>>> 0xbef00a64:    0x0
>>>>> 0xbef00a60:    0x0
>>>>> 0xbef00a5c:    0x0
>>>>> 0xbef00a58:    0x0
>>>>>
>>>>> And now I am clueless. So I tried the good old printf debugging in the
>>>>> rts. Using this, I see that it gets before the call to
>>>>> scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c).
>>>>>
>>>>> But when I put a printf in the beginning of scheduleWaitThread (in
>>>>> Schedule.c) it is not shown.
>>>>>
>>>>> What else can I do to find out more?
>>>>> Thanks!
>>>>> Nathan
>>>>>
>>>>> _______________________________________________
>>>>> ghc-devs mailing list
>>>>> ghc-devs at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>
>>>>
>>>
>>
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>