Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/link: darwin_amd64: running dsymutil failed: signal: segmentation fault #23374
Just to get this out of the way: a very similar issue was described in #23046, but I'm running a version of Go that includes the fix to that issue.
What version of Go are you using (
Thank you much!
That's Low Sierra and, I believe, XCode 9.2, but I don't know how to tell for sure given that I've only got the command line tools installed.
Inline in question is taking place within github.com/cockroachdb/cockroach/pkg/storage/engine/enginepb.(*MVCCMetadata).Size, at call to github.com/cockroachdb/cockroach/pkg/storage/engine/enginepb.(*MVCCStats).Size. Here is the bad inline info DIE:
The abstract origin for the second formal is off by 1 -- it is 0x83512d, should be 0x83512c. Not sure why... time to dig some more.
I think I finally have a handle on what's happening here. This was a very difficult bug to track down.
The problem seems to be that there are different versions of the abstract subprogram DIE being generated depending on whether we're compiling the package P containing an inlinable function F, vs. compiling some other package that imports P and uses F. Here is the abbreviation entry description for an abstract parameter:
Note the decl_line DIE -- it uses variable-length encoding, meaning the larger the line number, the more bytes consumed. Here is the inlinable function of interst:
When the package containing this function is compiled, the compile captures the declaration line of all interestin variables, meaning line 553 for 'm' and 'n' and 554 for 'l'. It emits an abstract function DIE with abstract param/local child DIEs based on this info.
The build continues for a while, then some other package that imports 'enginepb' and uses the method above. In this version of the compile, somehow the declaration line values for 'l' and 'n' are correct, but the line for 'm' is being set not to the correct line number but to the line number of the 'import' statement that pulls in enginepb (something about the fact that it is the receiver?).
Ordinarily nobody would care (hardly anyone looks at this sort of debug info) but in this case when the line number is LEB-encoded as the DIE is emitted, the block only takes one byte instead of the 2 bytes it takes to emit the correct line of 553.
This means that the offset of the next abstract parameter DIE ('n') in this case is computed differently (instead of the offset of 101 in the home package), we get an offset of 100, or vice versa.
Longer term we could track down the reason for the declaration line inconsistency, but it's not clear that there is an easy fix for that (since presumably it would mean making sure that it got written to the export data for the function).
changed the title
cmd/go: darwin_amd/64/link: running dsymutil failed: signal: segmentation fault
Jan 10, 2018
referenced this issue
Feb 2, 2018
I definite get
I think it is followed by
I'm compiling our internal software. It does not include Cockroach.
"running dsymutil failed" means that the Go toolchain produced a binary that was rejected by macOS's toolchain. There are myriad reasons this could happen—basically any misplaced bit during linking could cause this—and it's statistically unlikely that it happens to be the same problem that was addressed here.
I think you're best off filing another issue with a code sample that reproduces the issue!