GNU bug report logs - #20802
Segfault when showing non-GTK+ tooltip

Previous Next

Package: emacs;

Reported by: Tobias Getzner <tobias.getzner <at> gmx.de>

Date: Sat, 13 Jun 2015 09:19:02 UTC

Severity: normal

Tags: moreinfo

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: tobias.getzner <at> gmx.de, 20802 <at> debbugs.gnu.org
Subject: Re: bug#20802: Segfault when showing non-GTK+ tooltip
Date: Wed, 17 Jun 2015 19:39:20 +0300
> Date: Wed, 17 Jun 2015 11:36:25 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: tobias.getzner <at> gmx.de, 20802 <at> 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?




This bug report was last modified 3 years and 32 days ago.

Previous Next


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