-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
misc/cgo: testplugin fails on Darwin with runtime: bad pointer in frame
on the latest tip
#24653
Comments
Thank you @YoshikiShibata for reporting this issue! /cc @TocarIP @bradfitz, perhaps this just added CL https://go-review.googlesource.com/#/c/97255/ aka commit fd22542 |
runtime: bad pointer in frame
on the latest tip
runtime: bad pointer in frame
on the latest tipruntime: bad pointer in frame
on the latest tip
Duplicate of #23369 it seems? But actually hurting us now. |
I really don't want to roll back https://go-review.googlesource.com/#/c/97255/ (commit fd22542). It's innocent. It just tickled an existing bug. But re-disabling plugin support on Darwin would also be sad. |
/cc @mdempsky too |
The throwing part of the stack trace (from morestack to throw) has the PCs of runtime functions at 0x74xxxxx, whereas for goroutine 1 runtime.goexit and runtime.main have PCs at 0x40xxxxx. For one module, I think the linker will put all runtime functions together, adjacent in PC. So it seems that If I understand correctly, we suppose to always use the same runtime, right? This seems broken on darwin/amd64. |
We probably shouldn't even allow loading a plugin where the value of framepointer_enabled doesn't match that of the main binary. Even if we're using one runtime, this would make it unable to unwind frames created by the plugin. |
Apparently this is a todo. In
(where "correct toolchain" should include the experiments string) |
In this case, the plugin is indeed built with the "correct toolchain", and frame pointer is indeed enabled. But the linker doesn't set |
Okay, that makes more sense. (We should still check that it's compatible, but you're right that that's not the problem here.) |
To clarify, it's expected to have a copy of the runtime in the plugin (e.g., we could have dead-coded parts of it that the plugin needs, which is why in general we need all of the packages the plugin uses in the plugin), but the problem is that we're still seeing multiple copies after dynamic linking. It seems like which copy of the global the code sees depends on which copy of the code is executing. Some hypotheses @cherrymui and I have come up with:
|
Running in the debugger
which does seem to use GOT to load runtime.framepointer_enabled. However,
It is pointing to plugin1.so (note that we're in plugin2.so), not the main executable. Probably the main executable does not export the symbol, or the difference in segment/section (text/rodata vs. data/noptrbss) makes the dynamic linker resolve to the wrong one.
|
The symbol is not exported from the main executable:
(lowercase s means not exported) On Linux it is exported:
|
Change https://golang.org/cl/104715 mentions this issue: |
Thanks, @cherrymui! |
@gopherbot please consider for backport |
Backport issue(s) opened: #26202 (for 1.10), #26203 (for 1.9). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases. |
Please answer these questions before submitting your issue. Thanks!
What did you do?
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
Try to rebuild the latest tip version with
all.bash
What did you expect to see?
All tests would pass.
What did you see instead?
Does this issue reproduce with the latest release (go1.10.1)?
N/A
System details
The text was updated successfully, but these errors were encountered: