runtime: unexpected fault address 0x0 in hashmap.go #13062
Labels
Milestone
Comments
|
Anything in syslog or dmesg ? Can you please run with GODEBUG=gctrace=1 and add this output with a crash report.
|
|
why does nil pointer access trigger a SIGBUS instead of SIGSEGV?
|
|
Beyang, what are the specs of that .machine you're running this job on? On Tue, 27 Oct 2015, 17:09 Minux Ma notifications@github.com wrote:
|
|
Also, I'm very sorry to tell you that centos 5 is not a supported platform On Tue, 27 Oct 2015, 17:14 Dave Cheney dave@cheney.net wrote:
|
|
Thanks for the quick response here. I'll try to repro the issue on another Linux distro. I stepped out of the office and can't access the machine right now, but will do so in the morning. |
|
We were able to reproduce this on Mac OS X (compiling on Mac, running on Mac): And another error, panicked at a different place in hashmap.go but potentially related: This was running a srclib import on the elasticsearch library. I'm still working on creating a more minimal repro (the steps to process elasticsearch and import it are a bit involved, but I can post here if people think it'd be helpful). |
|
Please test this under the race detector, it is very common to see hashmap corruption due to data races. |
|
@davecheney Is hashmap corruption also possible for |
|
@neelance, data races can corrupt memory even with |
|
@bradfitz Thanks, that's what I thought. |
|
Please post the steps to reproduce this. Thanks. |
|
Without a way to reproduce this, we can't do much. |
You say there's no concurrency involved, but then you post a stacktrace with this: So, that's not really true. You're definitely doing concurrency. I suspect this is a data race and will close until we hear otherwise, especially given the lack of updates on this issue. |
|
CL https://golang.org/cl/17501 mentions this issue. |
mk0x9
pushed a commit
to mk0x9/go
that referenced
this issue
Dec 7, 2015
If reports like golang#13062 are really concurrent misuse of maps, we can detect that, at least some of the time, with a cheap check. There is an extra pair of memory writes for writing to a map, but to the same cache line as h.count, which is often being modified anyway, and there is an extra memory read for reading from a map, but to the same cache line as h.count, which is always being read anyway. So the check should be basically invisible and may help reduce the number of "mysterious runtime crash due to map misuse" reports. Change-Id: I0e71b0d92eaa3b7bef48bf41b0f5ab790092487e Reviewed-on: https://go-review.googlesource.com/17501 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Austin Clements <austin@google.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This involves a bus error that occurs when assigning to a local map with no concurrency involved. This happens within the context of a program that constructs a large in-memory index and consumes a lot of memory (~60GB) in the process.
Here's additional info about the environment:
Unfortunately, I have not been able to find a consistent repro for this. It happens about 25% of the time when running the program over a large dataset.
The hashmap assignment involves a local variable with no concurrency: https://sourcegraph.com/github.com/sourcegraph/srclib@2b53944d3fb5c9882f66bff716f396a0542eeec7/.tree/store/def_query_tree_index.go#startline=150&endline=150.
Issues #11286 and #12415 might be related, but don't appear to have the same underlying cause.
This issue does not seem to occur when
GOGC=off.Any ideas about what might be the cause here, or if there are known fixes or workarounds? I'm still trying to construct a reliable repro, but any advice/insight would be appreciated!
The text was updated successfully, but these errors were encountered: