http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56172
Ian Lance Taylor <ian at airs dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-02-02
Ever Confirmed|0 |1
--- Comment #1 from Ian Lance Taylor <ian at airs dot com> 2013-02-02 16:08:32
UTC ---
The error suggests that runtime_semawakeup was called with an m whose waitsema
field is NULL. There should be no way that kickoff can call runtime_semawakeup
directly, but it could be happening via a tailcall at the end of the function
that some goroutine was started to run. Possible tailcalls could come from
runtime_unlock or runtime_notewakeup. The stack trace shows that the goroutine
was started at mheap.c:408, and indeed that line starts a goroutine that runs
forcegchelper, and indeed forcegchelper ends with a tailcall to
runtime_notewakeup. runtime_notewakeup will look at the note's waitm field.
In this case the waitm field must be not NULL, and it must point to an m whose
waitsema field is NULL.
Unfortunately I don't see any way that could happen. The only m that could be
in the note is the one running runtime_MHeap_Scavenger. And that could only be
in the note if it calls runtime_notesleep before forcegchelper gets around to
calling runtime_notewakeup. And runtime_notesleep initializes the waitsema
field before it puts the m in the note.
Since you can recreate the bug, I guess the next step is to check the
mp->waitsema field in the runtime_semawakeup frame. My prediction is that it
is 0. But I'm not sure where to go from there since I don't see how it could
be 0.
And by the way I bet this is hiding something else, since the scavenger should
only run if nothing much else is happening, so once we fix this problem I
expect that the test will time out for some reason.
