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

Previous Next

Full log

Message #116 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 20:13:28 +0800

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?

If the answer to the final question is no, can anyone surmise how it is
that a live frame's image cache might be prematurely deleted without its
references being detected by verify_image_cache_refcount?

Previous Next

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