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

Previous Next

Full log

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Po Lu <luangruo <at> yahoo.com>
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, 9 Jul 2024 21:44:20 +0800

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.



-- 
Sean Whitton

Previous Next

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