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