Comment 1:

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

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.

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.

Comment 4:

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

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.

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.