-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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
go/parser: SIGSEGV in (*resolver).resolveList
#52046
Comments
cc @findleyr |
Is this likely related to go/parser, or the builders themselves? See also #51487. I'd guess the common denominator is that the resolver does a lot of allocation via map writes? For example, the scaleway failure is actually the following: CC @golang/runtime |
One more. Not clear to me whether this is related to
|
Given that the scaleway failure was unambigiously an OOM, and the other two failures are on linux-ppc64le-buildlet, I am inclined to think that this may be a builder problem (or a strange manifestation of OOM on ppc). But I have no idea how this could occur. |
Indeed, this seems to somehow be specific to
2022-04-20T20:19:07-5d7ca8a-24fcbb9/linux-ppc64-buildlet |
@pmur, what kind of overcommit policy does |
I can check (via osuol). The ppc64 builders don't enforce container ram limits like the ppc64le builders. I am not sure if the docker issues mentioned in the systemd unit file have been resolved (or whether they are tracked anywhere). I am guessing these use the default kernel overcommit options (mode 0 and 50% overcommit). I requested osuol bump the memory allocated to these VM's from 20 to 30GB. I think that change became effective in the last week. |
The segfault address on ppc64 looks suspicious. That kind of looks like an endian-swapped address based on how I've seen go grow it's heap on ppc64le. |
What address is suspicious with the wrong endianness?
This address looks reasonable. |
The value in the first comment |
2022-04-20T20:19:07-5d7ca8a-24fcbb9/linux-ppc64-buildlet is it possible a failed mmap wasn't handled somewhere? |
That address is indeed weird. But it doesn't look like a endianness-swapped address, which would be 0x000000001c6e3a83. The heap address is typically 0x000000c0xxxxxxxx. Perhaps it off by 32-bit, i.e. 833a6e1c should be the low 32-bit of something, not the high bits? |
Looking at other logs, it looks more like a bad pointer (2022-03-31T21:21:20-b9a4807-ff6b6c6/linux-ppc64le-buildlet). |
Pointers are usually printed as 8 byte values, but in this case it is printing it as 16 bytes so that is why it looks weird. I've seen addresses printed like this before. I don't think these are OOMs on Power -- if they hit OOM it would SIGKILL and not execute the rest of the tests. Interesting that it doesn't happen on power9. But the fact that it only happens in tests with golang.org/x/tools would make it seem like it is related to that package. Unfortunately it is hard to debug if we can't reproduce. But maybe get an idea of when it started happening? |
https://build.golang.org/log/0017fe5991c697b5529548a93953bc686e2ac01d looks like the same failure mode too, although because of the indentation I'm having trouble shoehorning it into a good
|
Paul tried to reproduce this problem but was unable to. |
2022-07-06T20:55:00-36430f4-b80ae10/linux-ppc64le-buildlet also looks related:
|
greplogs --dashboard -md -l -e 'goroutine \d+ \[running\]:\n(.+\n\t.+\n)*go/parser\.\(\*resolver\)\.resolveList' --omit=-n2d
2022-03-21T13:26:21-86b02b3-7eaad60/linux-ppc64le-buildlet
2021-04-28T19:13:50-16b25d2-ad989c7/linux-arm-scaleway
(CC @griesemer)
The text was updated successfully, but these errors were encountered: