-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/link: panic: sym already present in installSym on FreeBSD/amd64 #42772
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
CC @cherrymui @thanm Always hard to know what to do with a failure that only happened once, but perhaps the stack backtrace will suggest something. |
I tried to have that happen already, unfortunately the person who runs the CI system just said it was unlikely to be a memory issue and they had no other indications that this machine had problems and they weren't going to do it. EDIT: I have followed up with them to try and convince them again and will let you know if they agree to run memtest. They did agree to discuss it at least. |
Yeah. I think the linker, at least this part, is pretty deterministic. So if it happens nondeterministically, my guess is that the problem may be somewhere else, memory corruption (it could be the machine, the kernel, or could be the Go runtime), or object file corruption. |
I just had this exact same one happen again on another build; if it were just random hardware failures I wouldn't expect it to fail in the exact same place (though of course, they are the exact same tests behaving in exactly the same way on the same VM image on the same host machine so I suppose it's possible) |
More possibly related weirdness (that shows the same behavior as the others when I try to reproduce it):
|
If the traceback is to be believed, the third argument to loader.(*Loader).migrateAttributes is trashed (should be a sym.Symbol on the heap). This is even more similar to #42658 -- there it was a weird small value, here it is a weird huge value. Again, if there is any way you can get this to happen more reliably/reproducibly that would be a big help. |
I can always re-submit CI over and over again until it happens, I suppose. I have now seen it on two separate CI runners, so it's unlikely to be memory corruption on that one box. |
I have a quasi-reproducible crash similar to that:
FreeBSD 13-current in VirtualBox:
Go version:
Go env:
How to reproduce:
Notice how the error varies as it does the point of failure. Completely unable to reproduce in 11.4amd64, 11.4i386, 12.2amd64, 12.2i386. The 13-current virtualized machine has 16 GB of RAM assigned and I increased it to 20 just in case, but that doesn't seem to make any difference. There is plenty of disk space. This same virtualized machine built over 300 packages (llvm, gcc, cmake...) without problems the very same day. I don't think memory is bad. The physical machine in which this VirtualBox 13-current runs also builds packages without any problems. Just after a couple of minutes:
I removed the directory and try again and it failed with:
|
This happened on the same runner as #42658, though I don't see what that could have to do with anything unless I'm just very unlucky and these are hardware issues or something. Like that one, I can't reproduce it after the first time.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Unsure, it only happened once and I can't reproduce it again.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I ran
go test -v -cover ./...
againstmellium.im/xmpp
in CI.Build is here: https://builds.sr.ht/~samwhited/job/349374
What did you see instead?
The text was updated successfully, but these errors were encountered: