[Bug go/56172] net FAILs on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56172 --- Comment #6 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2013-02-07 17:04:37 UTC --- Author: ian Date: Thu Feb 7 17:04:24 2013 New Revision: 195855 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195855 Log: PR go/56172 net: Skip TestMulticastListener on Solaris From Rainer Orth. Modified: trunk/libgo/go/net/multicast_posix_test.go
[Bug go/56172] net FAILs on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56172 --- Comment #4 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2013-02-06 22:40:26 UTC --- Author: ian Date: Wed Feb 6 22:40:18 2013 New Revision: 195823 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195823 Log: PR go/56172 net: Fixes for select based pollster. Make Close work properly, mainly for testing. Restart the select if a descriptor is closed. Modified: trunk/libgo/go/net/fd_bsd.go trunk/libgo/go/net/fd_linux.go trunk/libgo/go/net/fd_select.go trunk/libgo/go/net/fd_unix.go
[Bug go/56172] net FAILs on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56172 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Ian Lance Taylor ian at airs dot com 2013-02-06 22:41:54 UTC --- The patch to mheap.c should fix this segmentation violation. As expected, there was another underlying problem, which should be fixed by the patch to the net package.
[Bug go/56172] net FAILs on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56172 --- Comment #3 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2013-02-05 23:59:28 UTC --- Author: ian Date: Tue Feb 5 23:59:24 2013 New Revision: 195774 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195774 Log: PR go/56172 runtime: Fix argument passed to forcegchelper. Modified: trunk/libgo/runtime/mheap.c
[Bug go/56172] net FAILs on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56172 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2013-02-04 13:00:59 UTC --- Thanks for the analysis. 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. In my case, mp-waitsema is 8. In case you want to have a look yourself (which will be way faster), you can find the build in apoc:/var/gcc/regression/trunk/11-gcc-gas/build/sparc-sun-solaris2.11/libgo/net-check/test. Rainer
[Bug go/56172] net FAILs on Solaris
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.
