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

Previous Next

Package: emacs;

Reported by: Sean Whitton <spwhitton <at> spwhitton.name>

Date: Thu, 4 Jul 2024 02:34:02 UTC

Severity: normal

Found in version 30.0.60

Done: Po Lu <luangruo <at> yahoo.com>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: luangruo <at> yahoo.com, 71929 <at> debbugs.gnu.org
Subject: Re: bug#71929: 30.0.60; crash in mark_image_cache
Date: Fri, 05 Jul 2024 09:27:07 +0300
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: 71929 <at> debbugs.gnu.org
> Date: Fri, 05 Jul 2024 08:13:14 +0800
> 
> Hello,
> 
> On Thu 04 Jul 2024 at 09:03am +03, Eli Zaretskii wrote:
> 
> >> What is the value of c->images?  IOW, why did this line segfault?
> >
> > Also, what is the value of c->refcount?
> 
> (gdb) p c
> $1 = (struct image_cache *) 0x555557c89e20
> (gdb) xpr
> There is no member named i.
> 
> (gdb) p c->images
> $2 = (struct image **) 0x35
> (gdb) xpr
> Cannot access memory at address 0x35
> 
> (gdb) p c->refcount
> $4 = 93823560581177

So it's garbled.

Po Lu, how do we handle the "shared" image cache when a frame is
deleted?  Where's the code which frees the cache if the cache's
refcount is one when the frame is deleted?




This bug report was last modified 301 days ago.

Previous Next


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