I've seen this same trace while testing tooltips in Banshee on openSUSE 11.0 with gtk2 2.12.9-37.1.  Line 865 of gtktooltip.c in that gtk2 package is this:

if (tooltip->keyboard_mode_enabled)

So that means that

tooltip = g_object_get_data (G_OBJECT (display),
                   "gdk-display-current-tooltip");

is returning NULL, right?

I think for me, it may be caused by in my OnQueryTooltip handler I'm currently (sometimes) setting the TipArea to something incorrect (outside the height/width of the screen).  Still, Gtk+ should probably be hardened against this, right?

Hrm, setting the rect x/y to a huge value (8123, for example) doesn't cause the crash.  Must be something else - maybe alternating setting it to a valid value and an invalid one.

I think the problem may be that in gtktooltip.c in the function gtk_tooltip_start_delay, the timeout_id is checked and that timeout removed if set, but the same isn't done for the browse_mode_timeout_id, whose callback destroys the tooltip.

It's bothering me that we don't see this all the time in other apps though; I wonder if I'm still doing something wrong/different than other gtktooptip users in my code.

CC'ing Kristian since he's the gtktooltip.c expert. :)

I patched gtktooltip.c and ran it, and it seems my thinking above was right.

Here's some debugging output I patched in.  You can see that start_delay is called, then browse_mode_expired (b/c the browse_mode_timeout_id wasn't 0) runs and destroys the tooltip, then the show_tooltip is run but the tooltip is now NULL.

gtktooltip.c: gtk_tooltip_start_delay, browse_mode_timeout_id = 215
gtktooltip.c: tooltip_browse_mode_expired
gtktooltip.c: gtk_tooltip_show_tooltip, tooltip is NULL, would have crashed here without this if statement

Created attachment 119551 [details] [review]
Patch that fixes the bug

This patch adds NULL checking in two places, removes the browse_mode_timeout if set in gtk_tooltip_start_delay - and properly sets the timeout_ids to 0 when removed in gtk_tooltip_start_delay.  AFAICT, this fixes the crasher I was seeing before.

(In reply to comment #3)
> I think the problem may be that in gtktooltip.c in the function
> gtk_tooltip_start_delay, the timeout_id is checked and that timeout removed if
> set, but the same isn't done for the browse_mode_timeout_id, whose callback
> destroys the tooltip.

If the tooltip is destroyed, the finalize method of the tooltip will unset both timeouts, so gtk_tooltip_show_tooltip() will never be called.  (Maybe this suggests a ref counting issue?)  Even though we might not want to destroy the tooltip from the browse mode timeout when a normal timeout is pending, destroying the tooltip from the browse mode timeout should not crash the application at this point.

> It's bothering me that we don't see this all the time in other apps though; I
> wonder if I'm still doing something wrong/different than other gtktooptip users
> in my code.

I actually want to get to the bottom of what is wrong here.  The stack trace of the bug report suggests that this problem also turns up in libwnck's window pager.  (But I can't see what would be wrong in there).


Do you have any more observations, suggestions?  As always stand-alone test cases are appreciated ;)  But I guess you don't have a clue on one either at the moment ...

*** This bug has been marked as a duplicate of 478519 ***

The part of my patch setting the timeout_ids to 0 and removing the browse_mode callback is still worth committing, isn't it?  Should I open a new bug for it?

It does seem like the finalizer should be getting run and preventing the segfaults.  I'll see if I can tell if the finalizer is getting run when it should from my C# app.

(In reply to comment #8)
> The part of my patch setting the timeout_ids to 0 and removing the browse_mode
> callback is still worth committing, isn't it?  Should I open a new bug for it?

The browse mode timeout should not be removed from gtk_tooltip_start_delay().  In case that tooltip popup is cancelled and another attempt is made, the browse mode might still be effective.