assert in rts/Schedule.c
Karel Gardas
karel.gardas at centrum.cz
Mon Jan 30 09:20:32 CET 2012
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))
GEq1: 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
Aborted
I've run several time and the output is still the same except the task's
address and the number of failed capability at the end of the output.
I'm curious if this is bug observable on slow hosts or we're hit by
ARM's weak memory ordering model here?
If this does not help you, please tell me what process you are using for
binary searching git's versions and I'll use it here to get to the patch
which caused. I.e. how to get certain date GHC git tree?
Thanks!
Karel
More information about the Cvs-ghc
mailing list