Building on android - compiled program segfaults
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); (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
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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
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? 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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
On Fri, Jan 11, 2013 at 12:36:22PM +0100, Nathan Hüsken wrote:
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?
Sounds like it would be useful to set a breakpoint on rts_evalLazyIO, disassemble, then "si" through the call to scheduleWaitThread to see what's happening. "info register someregistername" will tell you what's in someregistername. Thanks Ian
Ok, there I was a stupid. When I flush stdout I see the output of those printfs. The segfaults happens somehwere else (see the other answers). On 01/11/2013 02:31 PM, Ian Lynagh wrote:
On Fri, Jan 11, 2013 at 12:36:22PM +0100, Nathan Hüsken wrote:
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?
Sounds like it would be useful to set a breakpoint on rts_evalLazyIO, disassemble, then "si" through the call to scheduleWaitThread to see what's happening. "info register someregistername" will tell you what's in someregistername.
Thanks Ian
participants (3)
-
Ian Lynagh -
Nathan Hüsken -
Simon Marlow