bug#71929: 30.0.60; crash in mark_image_cache

[Po Lu]

Sean Whitton <spwhitton@spwhitton.name> writes:

> On Tue, Jul 09, 2024 at 08:13:28PM +0800, Po Lu via Bug reports for GNU 
> Emacs, the Swiss army knife of text editors wrote:
>> Sean Whitton <spwhitton@spwhitton.name> writes:
>> 
>> > On Sun, Jul 07, 2024 at 09:47:28PM +0800, Po Lu wrote:
>> >
>> >> I must ask you to bear with me again, as another detail was not
>> >> correctly accounted for in the last patch.  Please retry with this:
>> >
>> > This just crashed.  Apparent trigger was 'emacsclient -t', this time.
>> >
>> > verify_image_cache_refcount is not in the backtrace.
>> >
>> > I should be able to keep it open in a stable build of Emacs for at least 
>> > 24h
>> > if you'd like to ask for more.
>> >
>> > Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
>> > 0x00005555557a21cd in mark_image_cache (c=0x55555672cc50) at image.c:3776
>> > 3776               if (c->images[i])
>> 
>> And this is a segmentation fault, not a trap.  Can you establish when
>> the frame in question was created, how and where it received its current
>> image cache, and whether this frame exists in Vframe_list?
>
> I'm afraid I'm not familiar with any of these data structures.  I don't know
> what these image caches are.
>
> In the mark_frame stack frame I did "p f" to obtain the address
> 0x555559f61330.  I then did the "while $cons" thing you posted in another
> message, and searched its output for this address, and it is not present.
>
> So perhaps this means the frame is not present in Vframe_list.

OK, I believe I understand the source of these crashes.  A frame whose
image cache is shared among several frames is destroyed, but its
`image_cache' field is never cleared after it is destroyed, as its cache
continues to be referenced, and, if references to the dead frame remain,
GC attempts to mark the said image cache although its validity is no
longer guaranteed.  In earlier Emacs versions, this problem would have
appeared if references to dead frames were preserved beyond the
destruction of a display structure.  This has been corrected on the
emacs-30 branch, and therefore if the crashes do not resurface in a few
days, I will close this ticket.

Thanks.