runtime: SIGSEGV during map lookup

[adonovan]

I just observed this crash caused by a segmentation fault:

unexpected fault address 0xc2212e0000
fatal error: fault
[signal 0xb code=0x1 addr=0xc2212e0000 pc=0x4f75e4]

goroutine 1 [running]:
runtime.throw(0xa01ef7)
    /home/adonovan/go3/src/pkg/runtime/panic.c:480 +0x69 fp=0x7f3db4e663f0 
runtime.sigpanic()
    /home/adonovan/go3/src/pkg/runtime/os_linux.c:240 +0xe9 fp=0x7f3db4e66408 
code.google.com/p/go.tools/pointer.nodeset.diff(0xc21d83de80, 0xc21e7ca180,
0x7f3db4e665d0)
    /home/adonovan/go3/got/src/code.google.com/p/go.tools/pointer/util.go:172 +0xa4 fp=0x7f3db4e664b0 
code.google.com/p/go.tools/pointer.(*analysis).solve(0xc219a6a5a0)

The last frame of application code is this function:

type nodeid uint32
type void struct{} // a unitary type, for use in map-based sets.
type nodeset map[nodeid]void
...
func (x nodeset) diff(y nodeset) nodeset {
    var z nodeset
    for k := range x {
        if _, ok := y[k]; !ok {  // execution is inside this hash lookup
            z.add(k)
        }
    }
    return z
}

nil is a valid and common value of y in this code.

My executable (attached) was compiled using a 6g built from head on Jul 26.

The crash is not deterministic but occurs on about 10% of runs.

Attachments:

1. oracle (8513744 bytes)

[adonovan]

Comment 1:

% go version
go version devel +f3170d09181d Tue Jul 16 12:18:00 2013 -0400 linux/amd64

[cznic]

Comment 2:

Attaching the binary doesn't help. Show the code (cannot find it in the wild). 
What does 'z.add' do? 'z' is a zero value of a map thus 'z.add(k)' may panic, depending
on how its written (perhaps it's initialized lazily, but who knows). OR - Is your code
concurrently accessing nodesets?
BTW: The type aliases {nodeid,void} used seems like a non idiomatic coding style.

[adonovan]

Comment 3:

The code lives in a pending CL: https://golang.org/cl/10618043/.  I should have
made clear that I attached the binary so you could see (=disassemble) exactly which
hashtable implementation is being used, not with the expectation that you could
reproduce the crash by running it.  It will take extra work to get a hermetic
mostly-reproducible test case. 
Yes, the map is initialized lazily.  z.add is defined here:
func (ns *nodeset) add(n nodeid) bool {
    sz := len(*ns)
    if *ns == nil {
        *ns = make(nodeset)
    }
    (*ns)[n] = void{}
    return len(*ns) > sz
}
This code is not concurrent.
> BTW: The type aliases {nodeid,void} used seems like a non idiomatic coding style.
Maybe so for void, but I think nodeid is fine in the context; comment on the CL if you
like.

[randall77]

Comment 4:

Could you run it and get a trace with GOTRACEBACK=2?  Then I can see where in the
runtime it crashes.

[adonovan]

Comment 5:

I rebuilt the tools at head and ran the same test in a loop all night and didn't see a
single failure.  If you've made any changes since Jul 16 that could plausibly explain
this, we can regard it fixed.  I'll keep my eyes open for any reoccurrences.

[randall77]

Comment 6:

Nothing much has changed in the map implementation, but there's been plenty of other
churn that might be to blame.  Closing for now, reopen if you see it again.

Status changed to Retracted.