bug#71929: 30.0.60; crash in mark_image_cache

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: spwhitton@spwhitton.name,  71929@debbugs.gnu.org
> Date: Fri, 05 Jul 2024 17:36:49 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How does this answer my question?
> 
> I mentioned free_frame_faces.  That's the only function where image
> caches are released.
> 
> > The use case I was thinking of is that the image cache was shared,
> > then the last frame which shared the cache was deleted.  How do we
> > make sure the cache is freed and set to NULL in this situation?
> 
> The cache (whose refcount is 1) is released in free_frame_faces when it
> is called with this final frame, through free_image_cache, which also
> resets its `FRAME_IMAGE_CACHE' to NULL.
> 
> > IOW, we seem to have a cache that is not NULL but is also not a real
> > cache, as it cannot be accessed.  The question is how did that happen?
> 
> I don't know.  It can only be the case if its `refcount' was decremented
> excessively for a reason not yet understood.

Can you suggest a GDB setup for Sean to use in order to try to find
this unknown code which causes this?

Please note that this affects the release branch, and the changeset
which seems to have caused it was installed a couple of days before
the release branch was cut.  So if we cannot find and solve the
problem soon enough, I'd revert that changeset and solve the original
problem which it was supposed to solve on master, rather than leave
such a serious problem on the release branch.