New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
runtime: livelock near runtime.sysmon #11019
Comments
I believe sysmon was the unlucky recipient of the signal but otherwise uninvolved. The only places with consistent 100µs sleeps are the scheduler stealing and the GC work coordination (getfull). One of these seems to be running away / waiting for something that's not going to happen. |
I haven't seen this on recent versions, I think this is resolved. Thanks! |
I am having the same issue. golang version: OS version: [pid 1052205] 1457261183.644962 <... select resumed> ) = 0 (Timeout) |
@sagar8192, this issue is closed. We don't re-use old bugs. Please file a new issue if you found a bug. Please use Go 1.6 or master. You can reference this bug in your new bug report. Thanks. |
@bradfitz Lemme try my code with go 1.6. If it fails with the same error then I will open a new issue. Thanks! |
I have a process that receives data over a few hundred concurrent TCP connections and writes them to files. It's been locking up on recent versions of tip (it was stable on 1.4.1). When it locks up,
top
shows it consuming 10-30% of a core,perf top
doesn't show it at all, andstrace
shows it repeatedly callingselect(2)
with a NULL fd list (maybe used just as a sleep?). SIGABRT causes a stack dump which starts with a g0 stack (followed by goroutines from my app that have been blocked for many minutes).The text was updated successfully, but these errors were encountered: