After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 496546 - Tooltips may crashe because a window is destroyed
Tooltips may crashe because a window is destroyed
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.12.x
Other All
: Normal critical
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2007-11-13 19:56 UTC by Benjamin Berg
Modified: 2007-12-17 22:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Use weak references (2.10 KB, patch)
2007-11-13 20:10 UTC, Benjamin Berg
committed Details | Review

Description Benjamin Berg 2007-11-13 19:56:33 UTC
Steps to reproduce:
Not sure exactly, somehow trigger a tooltip timeout and then destroy the window. I do not have a foolproof way to reproduce it. First I had noticed it in gnome-screensaver, but also have been able to reproduce it with the "Add"/"Remove" button in the gedit file open dialog somehow.
The trick seems to be to hover over the button and then press escape so the window is destroyed.

Stack trace:
Sorry, not able to reproduce it right now (and did when I reproduced it). So here the details that I remember:

The crash occurs in gtk_tooltip_show_tooltip for the
    if (!GDK_IS_WINDOW (window))
test.

gtk_tooltip_show_tooltip is called from tooltip_popup_timeout.

Other information:
I think what is needed is to at least use weak references on the GdkWindow for last_window instead of just storing a pointer. It may also be a good idea to somehow check if the window is still visible (though not sure if that is needed).
Comment 1 Benjamin Berg 2007-11-13 20:10:04 UTC
Created attachment 99050 [details] [review]
Use weak references

I wrote this when I stumbled over it. However has not had any testing as I am currently not able to reproduce this reliably and I am not sure if this is the correct thing to do.
Comment 2 Benjamin Berg 2007-11-15 16:25:47 UTC
Ah, here a stack trace, just got the crash again.

(gdb) bt
  • #0 __waitpid_nocancel
    from /lib/libpthread.so.0
  • #1 IA__g_spawn_sync
    at /build/buildd/glib2.0-2.14.3/glib/gspawn.c line 373
  • #2 IA__g_spawn_command_line_sync
    at /build/buildd/glib2.0-2.14.3/glib/gspawn.c line 690
  • #3 ??
    from /usr/lib/gtk-2.0/modules/libgnomebreakpad.so
  • #4 <signal handler called>
  • #5 IA__g_type_check_instance_is_a
    at /build/buildd/glib2.0-2.14.3/gobject/gtype.c line 3115
  • #6 gtk_tooltip_show_tooltip
    at /build/buildd/gtk+2.0-2.12.1/gtk/gtktooltip.c line 854
  • #7 tooltip_popup_timeout
    at /build/buildd/gtk+2.0-2.12.1/gtk/gtktooltip.c line 974
  • #8 gdk_threads_dispatch
    at /build/buildd/gtk+2.0-2.12.1/gdk/gdk.c line 470
  • #9 g_timeout_dispatch
  • #10 IA__g_main_context_dispatch
    at /build/buildd/glib2.0-2.14.3/glib/gmain.c line 2064
  • #11 g_main_context_iterate
    at /build/buildd/glib2.0-2.14.3/glib/gmain.c line 2996
  • #12 IA__g_main_loop_run
    at /build/buildd/glib2.0-2.14.3/glib/gmain.c line 2900
  • #13 IA__gtk_main
    at /build/buildd/gtk+2.0-2.12.1/gtk/gtkmain.c line 1146
  • #14 main

Comment 3 Matthias Clasen 2007-12-09 07:00:46 UTC
Sounds about right to me.

Kris, any comment ?
Comment 4 Benjamin Berg 2007-12-14 15:28:09 UTC
As this happens every once in a while to me when unlocking the screensaver, I am now compiling a GTK version with the patch applied. This is not an ideal test, but lets see if I see the crash again in the next week or so.
Comment 5 Kristian Rietveld 2007-12-14 15:49:10 UTC
Putting on my list.
Comment 6 Kristian Rietveld 2007-12-17 15:40:53 UTC
Okay, analyzed the situation.  I think this bug usually does not turn up because:
  A) A key press event that will later destroy a window is still handled by the tooltips code, causing it the hide the tooltip.
  B) If so, the GDK_IS_WINDOW() in gtk_tooltip_show_tooltip() usually handles things good enough.

I realized that last_window can point to a totally bogus pointer in some cases after the "old" last_window was destroyed.  GDK_IS_WINDOW() can still crash then, while I was silently assuming that it wouldn't (very stupid assumption from my part).  The weak pointer magic will set this pointer to NULL, avoiding issues.


I committed your patch with minor changes on trunk in r19189.
Comment 7 Matthias Clasen 2007-12-17 15:52:31 UTC
Can we get the fix on the stable branch too, please ?
Comment 8 Kristian Rietveld 2007-12-17 22:52:34 UTC
(In reply to comment #7)
> Can we get the fix on the stable branch too, please ?
> 

done.