-
Notifications
You must be signed in to change notification settings - Fork 18k
runtime: segfaults in runtime.(*unwinder).next #73259
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
Comments
See also #73043 (comment), whose attached hypothesis is Windows-only. |
CC @golang/runtime. |
Looks like gp.m is nil, as 0x118 is the offset of incgo in the M. Though it would be good to disassemble a binary and double check. |
gp.m could become nil if we didn't suspend the G before doing traceback. But that seems unlikely to me, as I would expect that to cause much more spectacular failures (especially from the GC). I'd say more likely is that the stack somehow contains a function that isn't valid (triggering the ( I assume that this happens rarely and you can't reliably reproduce yet? |
Yeah, it doesn't seem to happen frequently. I've seen low double-digits of occurrences over a week across all of our production services. I just started investigating this morning and haven't yet reproduced the crash. |
Here's the disassembly of
Full output in case it helps
|
Thanks, that definitely looks like the dereference for m.incgo. |
@adonovan Your crash has a different fault address ( |
At Datadog, we've seen segfaults during
runtime.(*unwinder).next
. The programs are on Linux, running arm64 (in all the examples I've seen), on Go 1.24.1 and Go 1.23.6.Here is the first example, on Go 1.24.1:
The crash happens on this line, during a call to
runtime.Stack
triggered by callingpprof.Lookup("goroutine").WriteTo(w, 2)
. Unfortunately there are not goroutine addresses in this output (not sure why) so it's hard to tell which goroutine's stack was being unwound in this case.The other occurrence is in a different program, build with Go 1.23.6. It's segfaulting on the same line in
runtime.(*unwinder).next
, during garbage collection:The last goroutine appears to be the goroutine that was being scanned. The crash output ends there.
The text was updated successfully, but these errors were encountered: