I also have couple of questions about the stack trace:
It looks like our exception handler got fired because of EXCEPTION_ACCESS_VIOLATION (see signal 0xc0000005). The source code line where it happened must be mbarrier.go:73 - it is right before signal_windows.go:157 (runtime.sigpanic). Looking at that line: "if ptr != 0 && inheap(ptr) {", I don't see how it is possible for EXCEPTION_ACCESS_VIOLATION to be raised here. Can someone explain?
Also "runtime stack:" starts with runtime.mcall. But why? Who called it? Looking at remaining goroutine stacks, I see "goroutine 58 [runnable]" allocating memory at trace_test.go:149 with "_ = make([]byte, 1<<20)". But how did we get from allocating memory into runtime.mcall?
I suspect there is missing information here. Is it OK for it to be missing? How should I debug this crash?
Perhaps I am misreading this altogether.
Alex
The text was updated successfully, but these errors were encountered:
My mistake. I missed runtime.Gosched at the top of "goroutine 62 [runnable, locked to thread]". It calls mcall(gosched_m). But I still don't see how exception is possible at mbarrier.go:73.
mikioh
changed the title
runtime/pprof: unexpected signal during runtime execution
runtime/pprof: unexpected signal during runtime execution on windows-386-gce
May 2, 2015
I cannot reproduce it myself, but from windows-386-gce builder http://build.golang.org/log/e3bf7d994667518abb7f2a2f0064257d8c373927 while building 56a7c5b
I also have couple of questions about the stack trace:
I suspect there is missing information here. Is it OK for it to be missing? How should I debug this crash?
Perhaps I am misreading this altogether.
Alex
The text was updated successfully, but these errors were encountered: