runtime: fatal error: SIGSEGV during C.getaddrinfo #30310
Comments
agnivade
changed the title
agnivade
added
the
NeedsInvestigation
|
/cc @ianlancetaylor for CGo issues. Also probably helpful if you can try with 1.12rc1 and report back your findings. Thanks. |
|
Tracking the problem down to a change in resolv.conf is impressive. Changing the line in resolv.conf is most likely changing whether you are using the Go or C DNS resolver code. It would be interesting to see whether the problem recurs if you set the environment variable The stack trace shows that the C resolver code, which is part of glibc, is getting a segmentation violation. This is happening during a call to import _ "github.com/ianlancetaylor/cgosymbolizer"The might show us a stack trace in the C code. |
ianlancetaylor
changed the title
|
Hi guys, go1.11.5:
stack trace (cgo parts)fatal error: unexpected signal during runtime execution [signal SIGSEGV: segmentation violation code=0x1 addr=0x63 pc=0x7feb2e5ee1b9] go1.12rc1:
stack trace (cgo parts)fatal error: unexpected signal during runtime execution [signal SIGSEGV: segmentation violation code=0x1 addr=0x63 pc=0x7fd8b41641b9] (Cannot imagine how the "improved" traces help and both the traces seem to be same to me.) PS As for the "Tracking the problem down to a change in resolv.conf..." - one colleague of mine has recalled the similar issue in aws and he'd been able to track the critical change down... (magic NixOS, :-)) |
|
Thanks. You're right, of course: the extra stack traces didn't help. I guess that cgosymbolizer couldn't find the debug info for your C library. It appears that on your system calls to |
|
No problem. |
|
Hi,
|
|
Thanks. I didn't realize that you were using I cannot recreate the problem using When using Please double check whether you are using In general if you want to use |
I'm sorry, my mistake, I realised that the problem is actually with a built application when I was trying to prepare that code sample.
There might be a small misunderstanding here, I'll rewrite my conclusion:
OK, thank you. |
|
Thanks. I'm going to close this issue because unfortunately I don't think there is anything that the Go project can do to fix it. It's a bug in glibc, even though the glibc maintainers don't seem to have any plans to fix it either. The workaround is to use |
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
This is the latest version, I presume.
What operating system and processor architecture are you using (
go env)?go envOutputSystem (Xubuntu)
What did you do?
I've just run sets of my unit tests as usual.
What did you expect to see?
All tests passed.
What did you see instead?
I've come across these fatal errors when I was running some tests which had been OK before. (Meanwhile I'd upgraded my distribution).
Having discussed the issue with my colleagues we've narrowed a list of possible culprits down to a line as follows:
options edns0It's a line within the
/etc/resolv.conffile.Unfortunately I cannot claim that this option was not in use in the previous version.
However, when I comment that line out, all tests are OK again.
The most irritating symptom of the issue is that the SIGSEGV happens randomly - for instance when a set of tests failed because of one test failed, the same test running alone passes.
I've spent some time to generate a core file, in vain.
So the only thing I can give you at the moment is a couple of lines from a stack trace:
stack trace (shortened)
The text was updated successfully, but these errors were encountered: