On 30/01/2012 08:20, Karel Gardas wrote:
Hello Simon,
On 01/ 9/12 11:40 AM, Simon Marlow wrote:
On 06/01/2012 21:30, Karel Gardas wrote:
On 01/ 6/12 10:27 PM, Nathan Howell wrote:
I hit this one (might be the same?) on 7.2.1 on Linux x86_64:
ASSERT(t->cap == cap);
It happens somewhat frequently under load on a 16 core box.
Don't worry unless it also happens in 7.4.1 or HEAD.
Thanks for the information, however mine is previous one:
527
528 ASSERT_FULL_CAPABILITY_INVARIANTS(cap,task);
529 ASSERT(t->cap == cap);
530
and also this is on single-core ARM. Interesting...
This could be a problem. I haven't seen any of these in my builds. Does
it happen on the 7.4 branch or only HEAD?
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.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
