bug#20802: Segfault when showing non-GTK+ tooltip

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 17 Jun 2015 11:36:25 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: tobias.getzner@gmx.de, 20802@debbugs.gnu.org
> 
> I'm meanwhile quite confident that we cannot fix the problem with
> refcounts in the first place.  Consider the following scenario: First
> make sure that the *Backtrace* window will pop up on a new frame.  Then
> make sure that you can trigger its creation, for example, by specifying
> an invalid color as with the present bug.  Also let's assume we use a
> static variable old_refcount as our shadow copy of the "real" refcount.
> 
> Now the following will happen:
> 
> (1) x_create_tip_frame copies the current value of the real refcount
>      into old_refcount.
> 
> (2) The bug triggers and causes Emacs to pop up the *Backtrace* window.
>      ‘x-create-frame’ copies the value of the real refcount into
>      old_refcount and afterwards increments the real refcount.
> 
> (3) Now unwind_create_frame will be run for the tip frame we tried to
>      create in (1).  old_refcount won't equal the real refcount since the
>      latter was incremented in (2) so we leave the real refcount alone.
>      Subsequently we decrement the real refcount and the real refcount
>      will no longer reflect the number of frames referencing the object
>      it guards.
> 
> So IMHO we have to maintain for every object currently guarded by a
> refcount a list of the frames referencing the object.  Or, have each
> frame keep a pointer to all objects it needs and when deleting a frame
> look for each object it guards whether at least one other frame exists
> that guards the same object.  Suggestions welcome.

Why can't we simply move the code that frees the image cache to
delete_terminal?  There's only one image cache for each terminal, and
it's shared by all frames on that terminal, right?  And we call
delete-terminal when we delete the last frame on the terminal, right?