GNU bug report logs - #71929
30.0.60; crash in mark_image_cache

Previous Next

Full log

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

From: Po Lu <luangruo <at> yahoo.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 71929 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#71929: 30.0.60; crash in mark_image_cache
Date: Tue, 09 Jul 2024 22:03:34 +0800

Sean Whitton <spwhitton <at> 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 <at> 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.

Previous Next

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