bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

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.



-- 
Sean Whitton