runtime: "runtime: unexpected return pc for runtime.gopark called from 0x0" #23561
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
WaitingForInfo
Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Comments
ianlancetaylor
changed the title
|
Is it possible for you to try this with today's Go1.10rc1 release candidate? I think that will print more information. CC @aclements |
ianlancetaylor
added
NeedsInvestigation
|
@ianlancetaylor @aclements I can try, but I am not sure if it can happen again. |
|
It's interesting that after the panic, |
aclements
added
the
WaitingForInfo
|
@ianlancetaylor @aclements go1.10rc not support monotonic time? |
|
@YuleiXiao I don't know where that error message is coming from. It's not coming from anything in the Go distribution. I would guess that some code that you are using is not using build tags in the expected way. Go 1.10 does support monotonic time just as 1.9 does. |
|
@ianlancetaylor I know the panic where from. I have remove it and test it for a night, but gc crash not happen, I will test it for more time. |
|
i have similar issue while app running with go linux/amd64 1.9.2, 1.9.3 or 1.10rc1 . The go env is the same. In my case the go programm was compiled as a static library and started from c++ |
|
one trace for 1.10rc1: |
|
This looks like memory corruption. Have you tried running your program under the race detector? See https://blog.golang.org/race-detector . |
|
Dave, maybe you're right. and run application i have next message: I will dig deeper. |
|
@maxxant, are those trace backs complete? It's odd that none of the goroutines are marked as being scanned, but maybe it's a system goroutine that's causing the problem. Could you reproduce with |
|
@aclements @maxxant I open race and set |
|
For testing i wrote an application in pure Go that does roughly the same thing but it still running (no crashes), and the race detector is also silent. But for the test needs more time, of course. C++ & go lib crashed again. |
|
In my case everything C/C++ ::system() calls was removed from the code which used for execute miscellaneous tools and replaced with https://github.com/qt/qtbase/tree/5.11/src/3rdparty/forkfd (which internally used in Qt::QProcess). These ::system() calls are not related in the code with golang runtime and worked independently from C/C++ directly. Now the crashes are gone @YuleiXiao FYI |
|
TL;DR: @maxxant, do you have (or can you create) more crash tracebacks so I can look for patterns? The two tracebacks with "ThreadSanitizer failed to allocate" errors are something very different. I'm not sure if it's supported to build in both race mode and c-shared mode. The stack in #23561 (comment) is starting to reveal something. Here we can see goroutine 68 in a GC background worker scanning goroutine 3's stack. Goroutine 3 is the bgsweep system goroutine. It's parked in state "GC sweep wait", which is completely reasonable. But the arguments to The SP (0xc420046f40) is pretty close to the top of the stack (0xc420047000), which is reasonable for So, two of the words are correct, and nearly every other word is clearly incorrect. The two words that are correct make me think that we do have the right stack and it's just terribly corrupted. This almost looks like an overflow from the next stack in memory. This stack ends at 0xc420047000, which is half-way into a stack span, which will contain a total of 4 2K stacks. The 0xc4200476e8 on the stack is particularly concerning, since that points into what would be the next stack in the span. In fact, the next stack is goroutine 4's stack, which is At this point I'm kind of stuck, but getting more samples may help. |
bradfitz
removed
the
WaitingForInfo
|
@xiaoyulei, any update here? Do you still have problems? Does it work with Go 1.12 betas? |
bradfitz
added
the
WaitingForInfo
|
It looks good with later release, not happen again. |
|
Sounds like this is resolved. Feel free to reopen if this crops up again. |
|
Hi, everyone, I wrote a go project, which is used to wrap the access to ETCD and provide it to C language for use, https://github.com/dingrui37/etcdagent, (sorry for my poor English) |
|
|
@dingrui37 This issue was closed almost a year ago. You have a different problem. Please open a new issue. Or use a forum: https://golang.org/wiki/Questions. Thanks. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version)?go version go1.9.2 linux/amd64
Does this issue reproduce with the latest release?
I am not sure, it is not happen everytime.
What operating system and processor architecture are you using (
go env)?What did you do?
this happen when process in quit progress. I notify signal 15 to program.
What did you expect to see?
not crash
What did you see instead?
The text was updated successfully, but these errors were encountered: