It appears that I ended up with the threaded runtime. While not
optimal for debugging, I see this:
Breakpoint 1, schedule (initialCapability=0x1032b680, task=0x10336ec8)
at rts/Schedule.c:486
486 r = StgRun((StgFunPtr) stg_returnToStackTop, &cap->r);
(gdb) p cap->r
$6 = {rR1 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0}, rR2 = {w =
0, a = 0x0,
c = 0, f = 0, i = 0, p = 0x0}, rR3 = {w = 0, a = 0x0, c = 0, f = 0, i = 0,
p = 0x0}, rR4 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0},
rR5 = {w = 0,
a = 0x0, c = 0, f = 0, i = 0, p = 0x0}, rR6 = {w = 0, a = 0x0, c =
0, f = 0,
i = 0, p = 0x0}, rR7 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p =
0x0}, rR8 = {
w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0}, rR9 = {w = 0, a =
0x0, c = 0,
f = 0, i = 0, p = 0x0}, rR10 = {w = 0, a = 0x0, c = 0, f = 0, i =
0, p = 0x0},
rF1 = 0, rF2 = 0, rF3 = 0, rF4 = 0, rD1 = 0, rD2 = 0, rL1 = 0, rSp = 0x0,
rSpLim = 0x0, rHp = 0x0, rHpLim = 0x0, rCCCS = 0x0, rCurrentTSO = 0x301033c0,
rNursery = 0x1032f178, rCurrentNursery = 0x30100040, rCurrentAlloc =
0x30100060,
rHpAlloc = 0, rRet = 0}
After loading the thread state,
stg_returnToStackTop
{
LOAD_THREAD_STATE();
CHECK_SENSIBLE_REGS();
jump %ENTRY_CODE(Sp(0));
}
rightly barfs that registers are zero. Which function sets up those?
>From C or Haskell?
How can I select the single-threaded runtime?
Sorry for the abundance of questions...
Cheers,
Gabor
On 1/16/12, Simon Marlow <[email protected]> wrote:
> On 15/01/2012 00:07, Gabor Greif wrote:
>> Hello hackers,
>>
>> my "hello world" program compiles and links, but when running on the
>> embedded PowerPC board it crashes like this:
>>
>> (gdb) run
>> Starting program: /root/test
>> test: internal error: stg_ap_p_ret
>> (GHC version 7.5.20120111 for powerpc_unknown_linux)
>> Please report this as a GHC bug:
>> http://www.haskell.org/ghc/reportabug
>>
>> Program received signal SIGABRT, Aborted.
>> 0x0fdc0a4c in raise () from /lib/tls/libc.so.6
>> (gdb) bt
>> #0 0x0fdc0a4c in raise () from /lib/tls/libc.so.6
>> #1 0x0fdc2488 in abort () from /lib/tls/libc.so.6
>> #2 0x1029b300 in rtsFatalInternalErrorFn ()
>> #3 0x1029b024 in barf ()
>> #4 0x102b3f9c in stg_ap_p_info ()
>> #5 0x1029d0ac in scheduleWaitThread ()
>> #6 0x102c69a8 in rts_evalLazyIO ()
>> #7 0x1029ae80 in real_main ()
>> #8 0x1029afc8 in hs_main ()
>> #9 0x10002168 in main ()
>> (gdb) c
>> Continuing.
>>
>> Program terminated with signal SIGABRT, Aborted.
>> The program no longer exists.
>
> This back trace tells us almost nothing, I'm afraid - many different
> kinds of corruption end up as crashes in stg_ap_p_info or some other bit
> of the RTS.
>
> I suggest following the instructions in
>
> http://hackage.haskell.org/trac/ghc/wiki/Debugging/CompiledCode
>
> and see how far you get. Come back if you get stuck.
>
> Cheers,
> Simon
>
>
>
>
>>
>>
>> 'git grep' does not turn up any hits for 'stg_ap_p_info', and
>> 'scheduleWaitThread' looks pretty much innocent. Where is the best
>> place to get into debugging this?
>>
>> I gather stg_ap_p_info is a (global data) StgInfoTable, but then again
>> it appears in the backtrace, (tables beside code?). Why would it barf
>> at all?
>>
>> I am thinking that some host configury may still be leaking into the
>> target, so I might be fighting a deceived RTS ('revenge tastes best
>> when served cold'). But the host and target should be pretty
>> comparable linux OSs.
>>
>> I am thankful for any hints.
>>
>> Cheers,
>>
>> Gabor
>>
>> _______________________________________________
>> Cvs-ghc mailing list
>> [email protected]
>> http://www.haskell.org/mailman/listinfo/cvs-ghc
>
>
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
