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 78764 - bogus widget on event ...
bogus widget on event ...
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: general
0.x.x [obsolete]
Other Linux
: High critical
: 1.1.x
Assigned To: Michael Meeks
Nautilus Maintainers
: 83733 (view as bug list)
Depends on: 82366
Blocks:
 
 
Reported: 2002-04-15 14:24 UTC by Michael Meeks
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.0



Description Michael Meeks 2002-04-15 14:24:38 UTC
Ran nautilus; while it's starting up and can't really respond to events
right clicked on the desktop paused, did again, then several times.

When it got to rendering stuff (or later at least) I got:

(lt-nautilus:12991): Gtk-CRITICAL **: file gtkwidget.c: line 2933
(gtk_widget_event): assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)'
failed
Segmentation fault (core dumped)

With this:

  • #0 gtk_widget_get_toplevel
    at gtkwidget.c line 5030
  • #0 gtk_widget_get_toplevel
    at gtkwidget.c line 5030
  • #1 gtk_main_get_window_group
    at gtkmain.c line 1380
  • #2 gtk_main_do_event
    at gtkmain.c line 1205
  • #3 gdk_event_dispatch
    at gdkevents-x11.c line 1752
  • #4 g_main_dispatch
    at gmain.c line 1617
  • #5 g_main_context_dispatch
    at gmain.c line 2161
  • #6 g_main_context_iterate
    at gmain.c line 2242
  • #7 g_main_loop_run
    at gmain.c line 2462
  • #8 gtk_main
    at gtkmain.c line 912
  • #9 main
    at nautilus-main.c line 263
  • #10 __libc_start_main
    at ../sysdeps/generic/libc-start.c line 129
  • #1 gtk_main_get_window_group
    at gtkmain.c line 1380
  • #2 gtk_main_do_event
    at gtkmain.c line 1205
$3 = {type = GDK_MAP, any = {type = GDK_MAP, window = 0x84d20b0, 
    send_event = 0 '\000'}, expose = {type = GDK_MAP, window = 0x84d20b0, 
    send_event = 0 '\000', area = {x = 972977176, y = 0, width =
1082370048,height = 0}, region = 0x4058c000, count = 0}, no_expose = {type
= GDK_MAP, 
    window = 0x84d20b0, send_event = 0 '\000'}, visibility = {type = GDK_MAP, 
    window = 0x84d20b0, send_event = 0 '\000', state = 972977176}, motion = {
    type = GDK_MAP, window = 0x84d20b0, send_event = 0 '\000', time =
972977176, 
    x = 629, y = 99, axes = 0x0, state = 1024, is_hint = 0, device =
0x80d0848, 
    x_root = 629, y_root = 99}, button = {type = GDK_MAP, window = 0x84d20b0, 
    send_event = 0 '\000', time = 972977176, x = 629, y = 99, axes = 0x0,
state = 1024, 
    button = 0, device = 0x80d0848, x_root = 629, y_root = 99}
etc....
Comment 1 Owen Taylor 2002-04-15 14:30:29 UTC
Nothing I can do with theis bug within the context of GTK+
gtk_widget_get_toplevel() basically can't segfault unless
the widget tree is corrupted; it reads:

  while (widget->parent)
    widget = widget->parent;
Comment 2 Michael Meeks 2002-04-16 13:34:34 UTC
Well - the thing is that the widget pointer came from Gtk+ / Gdk,
examining the stack trace:

  • #0 gtk_widget_get_toplevel
    at gtkwidget.c line 5030
  • #1 gtk_main_get_window_group
    at gtkmain.c line 1380
  • #2 gtk_main_do_event
    at gtkmain.c line 1205
  • #3 gdk_event_dispatch

          ie. the bogus widget is obtained from the gdk event:

  event_widget = gtk_get_event_widget (event);

          or code like that in gtk_main_do_event, and that widget
pointer is dead on arrival.

          No nautilus code is involved with this AFAICS, it's pure
Gtk+, presumably some sort of race / re-enterancy with a destroyed
widget getting a map event.
Comment 3 Michael Meeks 2002-04-16 16:44:56 UTC
Ok, so this is really trivially repeatable, by doing the right click
thing on the root window a load of times.

The event_widget pointer at gtk_main_do_event is full of 0xaa, so it
looks as if someone is not setting the user_data correctly on the
GdkWindow on unrealize.
Comment 4 Michael Meeks 2002-04-16 16:59:36 UTC
Just read all the 'unrealize' handlers in eel/nautilus, they all chain
to the parent handler seemingly correctly - which should unset the gdk
window's user_data.
Comment 5 Luis Villa 2002-05-01 02:33:44 UTC
It appears michael meant to reassign to gtk; I'm clearing
milestones/priorities etc. but adding the gnome2.0.0 keyword.
Comment 6 Owen Taylor 2002-05-01 16:06:00 UTC
I suspect this would get fixed faster if it was assigned
to nautilus. While it might (or might not) be a GTK+
bug, as long as debugging it requires debugging nautilus,
it's better off IMO being with the other bugs that require
debugging nautilus. 

I doubt anything will be done to it while it is assigned
to GTK+ ... we have a lot of other bugs with less
than 100,000 line test cases.
Comment 7 Owen Taylor 2002-05-02 20:45:18 UTC
Not going to be fixed for 2.0.3 from our end. (or most likely
2.0.4, or ...)
Comment 8 Luis Villa 2002-05-14 22:41:43 UTC
Pushing out to 2.0.1 and moving all the way back to nautilus.
Comment 9 Michael Meeks 2002-05-20 15:26:10 UTC
hopefully the warning will get fixed in Gtk+, and perhaps the root
cause of this.
Comment 10 Luis Villa 2002-05-23 20:24:25 UTC
Michael: well, the gtk warning is not going to get fixed if this is
assigned to nautilus, no? [honest question, did I miss something
somewhere?]
Comment 11 Michael Meeks 2002-05-27 11:11:08 UTC
Yes - Owen removed the dependency of a Gtk+ bug, involving this
warning on this one - without comment, and without explanation, at
least that's what it looked like to me; Whatsup Owen ?
Comment 12 Michael Meeks 2002-05-27 11:13:30 UTC
the bug is #82366, and attempts to provoke the warning we get before
the crash, presumably exposing a false assumption in some Gtk+ / X
interaction. But perhaps not.
Comment 13 Owen Taylor 2002-05-27 20:50:30 UTC
I have not removed any dependences (what???)
Comment 14 Michael Meeks 2002-05-28 08:40:25 UTC
Strange; I got this mail: which makes it look like you removed the
dependency.

From: 
bugzilla-daemon@widget.gnome.org
To: 
nautilus-maint@bugzilla.gnome.org, michael@ximian.com,
nautilus-qa-maint@bugzilla.gnome.org
Subject: 
[Bug 78764] Changed - bogus widget on event ...
Date: 
20 May 2002 11:27:18 -0400	
Please do not reply to this email- if you want to comment on the bug,
go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=78764

Changed by otaylor@redhat.com.

--- shadow/78764        Mon May 20 11:26:12 2002
+++ shadow/78764.tmp.32749      Mon May 20 11:27:18 2002
@@ -12,13 +12,12 @@
 ReportedBy: michael@ximian.com               
 QAContact: nautilus-qa-maint@bugzilla.gnome.org
 TargetMilestone: 1.1.x
 URL: 
 Cc: 
 Summary: bogus widget on event ...
-BugsThisDependsOn: 82366
 
 Ran nautilus; while it's starting up and can't really respond to events
 right clicked on the desktop paused, did again, then several times.
 
 When it got to rendering stuff (or later at least) I got:
 
Comment 15 Luis Villa 2002-05-28 18:21:01 UTC
Possible it happened accidentally; browsers are sometimes funny about
'intelligently' clearing fields. I've readded it if no one objects.
Comment 16 Michael Meeks 2002-05-30 13:56:42 UTC
It is a crasher after all ... it looks like the gtk_widget_sink in
eel_popup_context_menu is the root of the problems.
Comment 17 Michael Meeks 2002-05-30 15:40:57 UTC
So; you can repeat this by right clicking repeatedly in a nautilus
window itself as well - it seems the bug is in Gtk+ which fails to
destroy the transfer_window if a grab fails. Patch on the Gtk+ bug
shortly.
Comment 18 Michael Meeks 2002-05-31 16:44:08 UTC
Fixed in Gtk+ now, on both branches.
Comment 19 Luis Villa 2002-06-03 21:31:25 UTC
*** Bug 83733 has been marked as a duplicate of this bug. ***