On Tue, Jul 2, 2019 at 4:20 PM Noam Postavsky wrote: > Michael Heerdegen writes: > > Pip Cet writes: > >> > Hmm - seems so, yes. I just made bootstrap with the commit > >> > included, and the problem is still gone. Strange thing, but seems > >> > there is nothing to fix. > >> > >> I'm not sure I agree. Something went wrong somewhere, or we wouldn't > >> have called byte code with what looks like an invalid hash table. > > > > Did you reply to the wrong thread - or - where is a connection to hash > > tables? > > 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. When we purecopy the hash tables emitted by the byte code compiler, Vpurify_flag is a hash table with predicate 'equal. That means the ->next vectors for different hash tables now might refer to the same pure vector. Rehashing such a hash table thus destroys another hash table's ->next vector, so it shouldn't happen. pdumper.c forces rehashing of many hash tables, including pure ones. The attached patch "fixes" things, at a high price. I'll try coming up with a proper fix soon if no one beats me to it. (To reproduce the problem, I added these lines to fn.c: DEFSYM (QCrehash_size, ":rehash-size"); DEFSYM (QCrehash_threshold, ":rehash-threshold"); DEFSYM (QCweakness, ":weakness"); + DEFSYM (QCgroup, ":group"); + DEFSYM (QCversion, ":version"); + DEFSYM (QCpackage_version, ":package-version"); + DEFSYM (QClink, ":link"); + DEFSYM (QCload, ":load"); + DEFSYM (QCtag, ":tag"); + DEFSYM (QCset_after, ":set-after"); DEFSYM (Qkey, "key"); DEFSYM (Qvalue, "value"); )