On 01/30/12 12:07 PM, Simon Marlow wrote:
up to 7.4.1 RC2 this was solely HEAD issue, now with 7.4.1 RC2 it shows
also on 7.4. The bug shows as:
internal error: ASSERTION FAILED: file rts/Schedule.c, line 506
(GHC version 7.4.0.20120126 for arm_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
The test which shows this fails always, so this is probably no race
condition. I've been able to get this for you:
$ ./GEq1 +RTS -Ds
40068000: created capset 0 of type 2
40068000: created capset 1 of type 3
40068000: assigned cap 0 to capset 0
40068000: assigned cap 0 to capset 1
40068000: allocated 1 more capabilities
40068000: new task (taskCount: 1)
40068000: returning; I want capability 0
40068000: resuming capability 0
40068000: cap 0: created thread 1
40068000: cap 0: thread 1 appended to run queue
40068000: new bound thread (1)
40068000: cap 0: schedule()
40068000: cap 0: running thread 1 (ThreadRunGHC)
40068000: cap 0: thread 1 stopped (suspended while making a foreign
call)
40068000: starting new worker on capability 0
40068000: new worker task (taskCount: 2)
40068000: returning; I want capability 0
40eff470: cap 0: schedule()
40eff470: giving up capability 0
40eff470: passing capability 0 to bound task 0x40068000
40068000: resuming capability 0
40068000: cap 0: running thread 1 (ThreadRunGHC)
40068000: cap 0: thread 1 stopped (suspended while making a foreign
call)
40068000: freeing capability 0
40068000: returning; I want capability 0
40068000: resuming capability 0
40068000: cap 0: running thread 1 (ThreadRunGHC)
40068000: cap 0: created thread 2
40068000: cap 0: thread 2 appended to run queue
40068000: cap 0: thread 2 has label IOManager
40068000: cap -1094678984: thread 0 stopped ((null))
This looks very suspicious - clearly the Capability is wrong (pointing
to the wrong place or the memory has been corrupted). If it reliably
fails in the same place, it should be easy to track down where it is
going wrong.
I recommend just debugging this directly, rather than trying to bisect.
Bisecting is difficult with GHC because we have multiple repositories
that have to be in sync, and also because each build takes a long time.
Even if you find the offending patch, it won't necessarily tell you what
the bug is.
The symptoms fit this bug, I bet it's the same problem:
http://hackage.haskell.org/trac/ghc/ticket/5824
I've patched my RC2 copy, rebuilt and running testsuite just now. So far
(few previously buggy tests just passed) it looks like the patch really
solves the issue.
However, may we discuss this a little bit? I'm curious why we need to
put registers which are saved at the beginning of function and restored
at its end into the clobber list? i.e.
StgRegTable *
StgRun(StgFunPtr f, StgRegTable *basereg) {
StgRegTable * r;
__asm__ volatile (
/*
* save callee-saves registers on behalf of the STG code.
*/
"stmfd sp!, {r4-r10, fp, ip, lr}\n\t"
#if !defined(arm_HOST_ARCH_PRE_ARMv6)
"vstmdb sp!, {d8-d11}\n\t"
#endif
[...]
/*
* restore callee-saves registers.
*/
#if !defined(arm_HOST_ARCH_PRE_ARMv6)
"vldmia sp!, {d8-d11}\n\t"
#endif
"ldmfd sp!, {r4-r10, fp, ip, lr}\n\t"
: "=r" (r)
: "r" (f), "r" (basereg), "i" (RESERVED_C_STACK_BYTES)
: "%r4", "%r5", "%r6", "%r8", "%r9", "%r10", "%fp", "%ip", "%lr"
);
now, r4-r10, fp, ip, lr are saved and restored and still we need to mark
them as clobbered in clobber list? If this is really required, then why
we do not also add r7 to the clobbered list and also d8-d11 (for ARMv7)?
I'm referring here to
http://ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#ss5.3 --
which explains GCC's clobber regs list. From this description I don't
see why we need to put those regs into clobbered lists as we correctly
restores them before returning to C world, but if there is really some
needs to do so, then my engineering guess is that we also need to do
this for d8-d11 and r7 too... I'm still quite lost in this GCC's inline
assembly support...
Ben, what do you think about it?
Thanks!
Karel
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
