On Sun, Mar 7, 2021 at 8:17 PM Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > Eli Zaretskii writes: > >> From: Andrea Corallo > >> Cc: 46256@debbugs.gnu.org, andrewjmoreton@gmail.com > >> Date: Sun, 07 Mar 2021 18:53:50 +0000 > What I think is going on here: > > The same .eln file is loaded two times, we detect that and try to reuse > the same compilation unit (the Lisp object) instead of a new one. > > We keep a pointer to the compilation unit representing the .eln file in > each .eln. Here we read it and we have it into 'saved_cu', we try to > dereference it and extract the CU with XNATIVE_COMP_UNIT but something > goes wrong. > > This object might have been GC'ed for some reason and we might be > looking at the same GC issue I've seen on 32bit wide-int (my guess). > *If* this is the case the question is: why is the CU GC'ed? Why wouldn't it be? I'm trying to follow along here :-) What I'm thinking is the CU got GC'ed, which is perfectly okay, but we never set its COMP_UNIT_SYM pointer to Qnil. Then we dlopen() the same file again, get the old handle, read the stale COMP_UNIT_SYM pointer, and dereference it. We should verify that the CU is indeed a different PVEC type now (ideally, PVEC_FREE), and then do something like the attached patch, shouldn't we? Pip