On Tue, Jul 2, 2019 at 10:50 PM Pip Cet wrote: > > The compiler translates repeated `eq' in a cond like that into a hash > > and jump. See byte-compile-cond-use-jump-table. > > I think I found the problem. It's a bit tricky. I'm attaching a patch which modifies standard Emacs in what should be harmless ways, but demonstrates the bug. As far as I can tell, this is a serious issue that will pop up seemingly at random. We really should fix it. However, I thought hash_table_rehash was called more often than it actually is, so the fix should be simple: just copy-sequence a hash table's ->next, ->hash, and ->index vectors before rehashing. (->key_and_value isn't actually modified, so it's safe to share between (read-only) hash tables. What's happening is this: Purecopied hash tables share structure, particularly the ->next vector, with similar but different purecopied hash tables. Some purecopied hash tables dumped with pdumper are rehashed upon first access after loading the dump (in the example, this is the tables which map 'dummy-symbol to t), while others are not (the tables with just fixnums as keys). If a hash table is rehashed, it's ->next vector will change to reflect the changed hash (of 'dummy-symbol); however, the non-rehashed table that shares the ->next vector will be confused: its key_and_value array will stay the same, and valid, but the ->next vector will no longer match it. In practice, this means (gethash valid-key hash-table) will return nil even though the key is valid. While the attached patch appears to work, I would prefer simply dumping hash tables with nil values for ->next, ->hash, and ->index, and rebuilding the entire hash table upon first access. This would also allow us to switch to secure randomized hashes should the need arise.