-
Notifications
You must be signed in to change notification settings - Fork 18k
plugin: net/http.Get fatals with "runtime: unexpected return pc for runtime.goexit called" #23133
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
Perhaps related to #20846? The traces are different though, and this is involving plugins. |
This seems to work for me on GNU/Linux. It's weird that the number 0x5466c00 appears both in the error message and in the call to |
CC @crawshaw |
I am seeing this as well in a similar situation. Version: My plugin uses https://github.com/atlassian/go-sentry-api which also appears to use |
This still happend in 1.10 rc1 darwin.amd64
I could reproduce this issue using this demo(https://github.com/nzlov/testplugin)
|
I've retitled the bug a little and @juhwany, it's cool to see you are already here as I just closed your duplicate issue in favor of this already existent one. |
This issue still happens in 1.10. and Go 1.10 release notes says that it supports plugin build on Darwin. |
It does look like there is something strange going on. When I add this line to goroutine creation:
Most of the time, it prints:
But sometimes, it prints:
Those two values should always be the same (startup does The first value printed is correct, it is the address of the On Darwin, I see the following symbols:
On Linux, there's something different:
I'm not sure if that's relevant. @crawshaw @ianlancetaylor , any ideas? |
I'm not familiar with how dynamic linking works on MacOS. But this looks like the failing code is running inside the plugin. It's essential for correctness that the main executable and a shared library agree on the location of a global variable. So it's not surprising that the plugin gets the value of If my guess is correct then the simple fix is to introduce a package scope variable initialized to |
That was the fix I was thinking of, but I was worried that there might be a larger issue that this was just the tip of the iceberg for. But maybe you're right, the only issue is function address equality, and as long as we don't rely on that across packages, it's ok if the plugin and main program are using two different runtimes with identical contents. As long as all the mutable global variables are shared.
|
Audit of uses of funcPC:
Long story short, the |
I don't see any particular problem with The problem with |
Or to put it another way, in effect only a single copy of the runtime functions will ever be used, with one exception: explicit calls to |
I don't think that last statement is correct. We are clearly using two copies of
to
Sometimes it is the main executable's
Which means that the actual PC of runtime functions on the stack won't be the same in plugin vs main instances. And I suspect, but haven't confirmed, that we get separate symtab entries with different |
Thanks for checking. I clearly do not understand how shared libraries work on Darwin. |
We are both in the same (sinking) boat. |
Change https://golang.org/cl/100739 mentions this issue: |
Still wrong...
|
…nstead of address When there are plugins, there may not be a unique copy of runtime functions like goexit, mcall, etc. So identifying them by entry address is problematic. Instead, keep track of each special function using a field in the symbol table. That way, multiple copies of the same runtime function will be treated identically. Fixes #24351 Fixes #23133 Change-Id: Iea3232df8a6af68509769d9ca618f530cc0f84fd Reviewed-on: https://go-review.googlesource.com/100739 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-on: https://go-review.googlesource.com/102793 Run-TryBot: Andrew Bonventre <andybons@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
@andybons @randall77 why closed this issue?
|
Sorry, the closing is just from the automated point release process. |
@randall77 Thanks. |
Sorry about that. Moved to 1.10.2 milestone as well. |
@gopherbot please open a 1.10 backport tracking issue. Go 1.10.1 only included a partial fix. |
Backport issue(s) opened: #25038 (for 1.10). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases. |
I have confirmed that this issue has been resolved on GO 1.11 beta |
Thanks. |
@FiloSottile @ianlancetaylor @andybons, @randall77's first CL 100739 was already backported to Go1.10 with CL 102793 but @randall77 reopened this issue in #23133 (comment) mentioning that his CL fixed a part of this issue. How do we proceed with closing the requested backport issue #25038? |
I think the other half is CL https://go-review.googlesource.com/c/go/+/104715. So CL https://go-review.googlesource.com/c/go/+/122116 will do. |
Cool, thanks for finding and reporting that @cherrymui! I don't think we should tamper with editing that backport message in CL 122116, to state that it finishes up this one, so perhaps this conversation in here suffices. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
YES
What operating system and processor architecture are you using (
go env
)?What did you do?
Call
http.Get
in plugin.Like:
plugin.go
main.go
DEMO
What did you expect to see?
Get Google Website
What did you see instead?
The text was updated successfully, but these errors were encountered: