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

[martin rudalics <rudalics@gmx.at>]

 > Thanks.  Now I know why this cannot be reproduced on Windows: this is
 > bug#17524 coming back to haunt us.  That bug was reported on Windows,
 > I fixed it on Windows, then suggested a similar fix for X, but was
 > told it didn't help there.
 >
 > So now please try making a fix on X similar to commit ebdc80316, and
 > if that indeed doesn't help with this crash, perhaps some simple
 > variation of that will.

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.

martin