The attempt to put two particular keys into the same hash-map will stackoverflow: http://dev.clojure.org/jira/browse/CLJS-1976

https://github.com/google/closure-compiler/issues/2336#issuecomment-286215992

the async fix will be in the next version of Google Closure Compiler

@favila The two keys hash to the same value.

I'd guess that the Hash collision node has faulty logic for a transient assoc

I don't have the same hash?

If I try (hash-map (hash bad-key)-1 nil (hash bad-key-2) nil) it works correctly

cljs.user=> (hash bad-key-1)
1454955434
cljs.user=> (hash bad-key-2)
-2840011862

@spinningtopsofdoom normal assoc fails too

-2840011862 === 1454955434 when you're using 32 bit ints

it is common to both transient and non-transient

ah, it is not truncating

hashes should really be normalzied to 32bit

so maybe it doesn't detect a collision because it's comparing by value

@favila You are correct It doesn't detect a hash collision because it's comparing by value

create node compares hashes by ==

@spinningtopsofdoom I am preparing a proper patch

Replaced that with (zero? (bit-xor hash-a hash-b))

but really, it's not good that the record impl of hash is producing > 32 bit vals

but who knows who else is doing that

It's not greater than 32 bit. It's a negative value that falls within a the range of a singed 32 bit int

I mean it's using more than 32 bits

in particular, hash-imap does not bit-or 0 it's return value

nor hash iset

hm, nor any of the hash-* fns

nm only those two matter. hash-combine truncates

which takes care of hash-coll

ah, defrecords don't use murmur hashing

hash-imap and hash-iset are pre-murmur

so that's a possible future enhancement

Now that I know the cause, here is a much simpler reproducer: (hash-map #inst "2017-03-13T22:21:08.666-00:00" nil #inst "2015-11-02T19:53:15.706-00:00" nil)

That blows the stack

Added a patch which forces hash to return 32-bit values

Also made this as a followup: http://dev.clojure.org/jira/browse/CLJS-1977