From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27992 invoked by alias); 2 Feb 2013 16:08:56 -0000 Received: (qmail 27606 invoked by uid 48); 2 Feb 2013 16:08:34 -0000 From: "ian at airs dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug go/56172] net FAILs on Solaris Date: Sat, 02 Feb 2013 16:08:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: go X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ian at airs dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ian at airs dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Status Last reconfirmed Ever Confirmed Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2013-02/txt/msg00134.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56172 Ian Lance Taylor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2013-02-02 Ever Confirmed|0 |1 --- Comment #1 from Ian Lance Taylor 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.