Building on android - compiled program segfaults
marlowsd at gmail.com
Fri Jan 11 15:36:27 CET 2013
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,
> 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.
> On 01/11/2013 02:16 PM, Simon Marlow wrote:
>> On 11/01/13 11:36, Nathan Hüsken wrote:
>>> I was succesfull in building ghc (pulled from git) to compile for
>>> Now using "inplace/bin/ghc-stage1 -dcore-lint -debug" I compiler this
>>> 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?
>>> (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?
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
More information about the ghc-devs