Comment 1:

Owner changed to ---.

Comment 2:

Fails on Mac too.

Labels changed: added priority-asap, removed priority-triage.

Owner changed to @dvyukov.

Status changed to Accepted.

Comment 3:

It's a straighforward but very serious bug.  The hashmap code uses a uint8 to store the
size of a data element.  That means that the hashmap code fails if the total of the key
size plus the data size, with appropriate rounding, is >= 256.  That was fine before Go
1, but it failed once we started to permit struct and array values to be used as hash
keys.
But strangely there is already an assertion to check for this type of error in hash_init:
    assert (h->datasize == datasize);
Ah, but it doesn't work because the caller uses h->valoff, which is itself a uint8 field.
Here is a possible fix but I'm not sure it's ideal or complete:
http://golang.org/cl/6137051

Owner changed to ---.

Comment 4:

Labels changed: added go1.0.2.

Comment 5:

This issue was closed by revision bf18d57.

Status changed to Fixed.

Comment 6:

This appears not to be fixed at tip.
$ go tool 6g -V
6g version weekly.2012-03-27 +d8e47164f8dd
The following code demonstrates a variety of errors:
package main
import "fmt"
const id = "scaf" // or var id = "scaf" or other values - see comments below
type sf struct {
    id string
    i  int
}
type sp struct {
    a, b sf
}
func main() {
    seen := map[sp]struct{}{}
    for i := 0; i < 500; i++ {
        fmt.Println(i)
        a := sf{id, i}
        aa := sp{a, a}
        seen[aa] = struct{}{}
    }
}
The results depend on the value of and 'type' of id:
if it's const "" then the result is always a `throw: hashmap assert`, if it's a var ""
then it's either that or `invalid memory address or nil pointer dereference`
if it's const or var "a" then mainly `unexpected fault address`, but sometime `hashmap
assert'
if it's const or var "scaf", sometimes it hangs and sometimes it throws `hashmap assert`
- other '4-words' behave differently (id ~< "naaa" behaves like "a", id ~> "naaa"
behaves like "scaf" - not exhaustively confirmed for all values)
The common thing is that the throw or hang always happens as i == 81.
Removing the integer or the string field results in normal behaviour.

Comment 8:

Note that the problem reported in comment 6 became issue #3695, now fixed.