GNU bug report logs - #42832
28.0.50; "Bus error" when compiling Emacs now on Debian bullseye

Previous Next

Full log

Message #71 received at 42832 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 42832 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#42832: 28.0.50; "Bus error" when compiling Emacs now on
 Debian bullseye
Date: Fri, 14 Aug 2020 14:24:48 +0000

On Thu, Aug 13, 2020 at 2:08 PM Pip Cet <pipcet <at> gmail.com> wrote:
> All that sounds to me like we ought to dig down into the core file and
> figure out what happened, since the issue is likely to remain present
> otherwise and it seems somewhat difficult to track down and reproduce.

I have a theory, and it sounds like a somewhat silly bug.

- there's a hash table h in the dumper image
- h->hash points to dynamically allocated storage (as it always does
after my patch)
- the last reference to the hash table dies
- garbage_collect is called and collects h->hash
- h->hash's storage is reallocated for a different vector with a
different start position
- a word (re)appears on the stack which looks like it's a pointer to h
(it isn't, actually)
- garbage_collect is called and calls mark_maybe_pointer(h)
- h is recognized as a pdumper object
- h->hash is marked
- we're now marking a word in the middle of the new vector that
occupies the space that h->hash used to occupy
- in our case, this word is 0xc000000018000005, which is interpreted
as a tagged pointer, dereferencing of which leads to SIGBUS

Is there something which I'm missing which would prevent this scenario?

If no, any ideas on how to fix it? The obvious fix would be to always
mark all pdumped objects, but that has a performance cost. Less
obvious would be clearing the memory in the pdumper image that belongs
to an object that's being "freed", or keeping track of which pdumper
objects are still valid after GC...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.