cmd/link: runtime crash, unexpected fault address 0xffffffffffffffff, h2_bundle.go, when using plugin #44586
Comments
seankhliao
changed the title
seankhliao
added
the
NeedsInvestigation
|
One possibility where this address can come up is that a method is called which the linker decided unreachable, possibly a linker bug. At h2_bundle.go:7825 it seems an interface method call of the Close method. Do you know what the concrete type that interface value is? Is it possible to share the whole program? Thanks. |
|
Well, the whole program is Gopherbot - https://github.com/lnxjedi/gopherbot All the http code is either in the Is there a debug flag I can pass during build that might catch this during linking? |
|
At the moment it is probably most useful to know what the concrete type is. Maybe you can add a print, something like There are linker debug flags but it is not that helpful without knowing the type. Also, it would be helpful to know how the program is built, e.g. a static executable, or with shared libraries, or plugins. Thanks. |
|
Huh. Never realized I could just edit files in /usr/local/go/src/..., but yeah, that worked: Here's an excerpt from Thanks for digging in to this. |
|
Thanks for the information. This is helpful. Could you try CL https://golang.org/cl/296709 ? It should apply cleanly to Go 1.16. Thanks. |
|
Change https://golang.org/cl/296709 mentions this issue: |
|
Ok, I ended up cloning & building go from source (after I assume this will eventually show up in a merged PR with |
|
Thanks for confirming. Yes, it will. |
cherrymui
changed the title
|
@gopherbot please backport this to Go 1.16. This is a regression causing runtime crash without easy workaround. |
|
Backport issue(s) opened: #44638 (for 1.16). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases. |
|
Change https://golang.org/cl/296910 mentions this issue: |
…ace when dynlink When using plugins, a type (whose value) may be pass to a plugin and get converted to interface there, or vice versa. We need to treat the type as potentially converted to interface, and retain its methods. Updates #44586. Fixes #44638. Change-Id: I80dd35e68baedaa852a317543ccd78d94628d13b Reviewed-on: https://go-review.googlesource.com/c/go/+/296709 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> (cherry picked from commit a655208) Reviewed-on: https://go-review.googlesource.com/c/go/+/296910
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)?go envOutputWhat did you do?
I'm going to need some suggestions on figuring out what happened, but the gist is I ran my program and it crashed with a strange segfault.
What did you expect to see?
Program running as it did with Go 1.15.8.
What did you see instead?
My program crashed with a segmentation violation; I've pasted in the stack trace (in a details section) below.
./gopherbotstack traceNote that if I run the same program with a different configuration (connecting to Slack or not, but so far I've had no luck in finding a the causal link), it doesn't crash. Hopefully someone more knowledgeable than I can make some sense of the dump and suggest something to look for in my code - but the actual thread that crashed appears to have been created entirely within the runtime, so I'm at a loss.
The text was updated successfully, but these errors were encountered: