Subject: bug#76133: 31.0.50; feature/igc: crash using mu4e, 2025-02-07

From: Pip Cet <[email-masked]>
Date: Sun, 09 Feb 2025 11:43:51 +0000

"Eli Zaretskii" <[email-masked]> writes:

>> Date: Sun, 09 Feb 2025 10:36:28 +0000
>> From: Pip Cet <[email-masked]>
>> Cc: Oliver Reiter <[email-masked]>, [email-masked]
>>
>> "Eli Zaretskii" <[email-masked]> writes:
>> > Somewhere there you will probably see an invalid Lisp object, and we
>> > will then need to look at it and try to understand where it came from
>> > and why.
>>
>> I'm not sure why you think this crash, which matches the behavior which
>> would be caused by bugs that have since been fixed on feature/igc,
>> warrants further investigation.  If there's a good reason, we can spend
>> time establishing that it is indeed that bug, but if there isn't, it's
>> most likely a fixed bug and we probably shouldn't waste time on it,
>> particularly not time which isn't our own to waste.
>
> I just don't yet understand the root cause of this crash.  We had in
> the past crashes similar to this, due to invalid Lisp objects, which
> had nothing to do with GC.  I thought it would be good to see what
> that object is before we decide this was solved.

The Lisp object in question (0x7fffa7debfb3) was stored in the specpdl,
then retrieved from it.  We know that our code to resize the specpdl was
buggy and may have resulted in stale pointers after a resize happened.

> Why are you sure this bug was already fixed?

I'm not sure, I just think it's likely enough we might want to wait for
a new crash report if it hasn't been fixed :-)

> And which change you think fixed it?

6654ac61342, because that fixed things so pointers in the specpdl area
wouldn't silently go stale.

Pip