GNU bug report logs - #76238
31.0.50; feature/igc: crash #2, 2025-02-12

Previous Next

Full log

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76238 <at> debbugs.gnu.org, oliver.reiter <at> snapdragon.cc
Subject: Re: bug#76238: 31.0.50; feature/igc: crash #2, 2025-02-12
Date: Fri, 14 Feb 2025 16:45:13 +0000

"Eli Zaretskii" <eliz <at> gnu.org> writes:

>> Date: Fri, 14 Feb 2025 15:15:36 +0000
>> From:  Pip Cet via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> "Oliver Reiter via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org> writes:
>>
>> This is one of a number of bugs in which a string data object is
>> recycled but the string metadata object is still present.
>
> Why and how does this happen?

Good questions.  My question is why it doesn't happen here!

> And if it can happen for strings, can't it also happen for other Lisp
> objects?

Most likely, yes.

Right now, the feature/igc branch doesn't poison memory that MPS has
told us might be reused and no longer should be used, so many UAF errors
would go undetected.  (This is the same way alloc.c GC behaves).

Strings are special because their data is stored in a separate pool, so
the UAF is detected more drastically, but by the time we detect it, it's
too late to know what the string was.

I've modified my local branches to poison memory and collect garbage
eagerly, but I haven't been able to produce bugs like this one (only
local ones which I've fixed, I'm afraid).

I did mark string data objects for finalization, and it seems we free
many of them that I thought would be reachable from pdumper objects.
Investigating that one...

Pip

Previous Next

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