runtime: deeply nested struct initialized with non-zero values #46653
Comments
seankhliao
added
the
NeedsInvestigation
|
This looks like a linker / objwriter issue. Building crash.go with "-S", I see: however when I inspect the binary, the map.zero symbol has a smaller size: I think what's happening here is that because the symbol is marked as a regular DUPOK symbol as opposed to having hashed content, there are multiple go.map.zero symbols at link time, and we wind up picking a smaller one. There is actually code in the linker to detect this problem (under debug option -strictdups) but the code written to check data payload length and not symbol size (in this case there is no payload since it's essentially a BSS symbol). Bummer. I'll work on a fix. |
|
Change https://golang.org/cl/326211 mentions this issue: |
|
Change https://golang.org/cl/326210 mentions this issue: |
|
@gopherbot please consider this for backport to 1.15 and 1.16 |
|
Backport issue(s) opened: #46656 (for 1.15), #46657 (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. |
thanm
added
NeedsFix
|
@d-reinhold thank you for reporting this bug. I have a tentative fix. It looks like this bug is also present in 1.15 and 1.16, so I will consult with the release team regarding back-porting the fix. |
The linker's -strictdups debugging option was not properly checking for cases where you have two dupok BSS symbols with different length (the check examined data length and content, but not symbol size). Updates #46653. Change-Id: I3844f25ef76dd6e4a84ffd5caed5d19a1b1a57c9 Reviewed-on: https://go-review.googlesource.com/c/go/+/326210 Trust: Than McIntosh <thanm@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
|
@thanm Thanks for the quick fix! Looks like it's working against my test-case on master. Those backports will be appreciated as well! |
|
Change https://golang.org/cl/326212 mentions this issue: |
|
Change https://golang.org/cl/326213 mentions this issue: |
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes, the issue is reproducible on the go playground (1.16.5).
What did you do?
This program instantiates a deeply nested struct by accessing an empty map.
What did you expect to see?
Per the go spec, this access should return a zero valued instance of the struct type.
What did you see instead?
The
stringfields five levels deep in the struct are initialized with values of enormous lengths:The program does not crash.
A slightly different version of this program forces the runtime stack to expand after initializing the corrupt struct, which causes the program to crash (this "bad pointer in frame" crash occurred in a production application, which motivated this investigation):
Slightly changing the depth/breadth of the nested struct can cause the issue to disappear, or can cause other, stranger behaviors:
In the context of my application, I have also seen the
stringfields be initialized with real string values from somewhere else in the application's memory:At other times, the application has consumed all system memory attempting to print the struct:
The text was updated successfully, but these errors were encountered: