Re: Loads of crashes in the panel / gwmh.c (gnome-core 1.4.x)



tir, 2002-08-06 kl. 14:10 skrev Kjartan Maraas:
> ons, 2002-04-24 kl. 07:22 skrev Kjartan Maraas:
> > Hi all.
> > 
> > We've received a whole lot of crash reports in bugzilla for 1.4.x that
> > points to problems with the desk-guide code, more specific - list
> > handling in gwmh.c. It could be specific to the panel and it could be
> > deskguide/tasklist specific.
> > 
> > Take a look at http://bugzilla.gnome.org/show_bug.cgi?id=59500 to see
> > the buglist.
> > 
> > I've compiled a panel with efence linked in and a hacked glist.c (from
> > owen) to make things more visible and this is the backtrace I get:
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 1024 (LWP 1345)]
> > gdk_window_add_filter (window=0x43f3dfcc, 
> >     function=0x805a538 <task_event_monitor>, data=0x44078f98)
> >     at gdkwindow.c:1966
> > 1966	      if ((filter->function == function) && (filter->data == data))
> > (gdb) bt
> > #0  gdk_window_add_filter (window=0x43f3dfcc, 
> >     function=0x805a538 <task_event_monitor>, data=0x44078f98)
> >     at gdkwindow.c:1966
> > #1  0x0805bafc in task_new (window=0x43f3dfcc) at gwmh.c:1726
> > #2  0x0805be9c in client_list_sync (xwindow_ids=0x440b6fcc, n_ids=1)
> >     at gwmh.c:1862
> > #3  0x0805ac8d in gwmh_desk_update (imask=GWMH_DESK_INFO_CLIENT_LIST)
> >     at gwmh.c:1100
> > #4  0x0805b54e in gwmh_idle_handler (data=0x0) at gwmh.c:1490
> > #5  0x404b7ddc in g_idle_dispatch (source_data=0x805b510, 
> >     dispatch_time=0xbffed6f0, user_data=0x0) at gmain.c:1367
> > #6  0x404b6e41 in g_main_dispatch (dispatch_time=0xbffed6f0) at
> > gmain.c:656
> > #7  0x404b7445 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
> > #8  0x404b75d4 in g_main_run (loop=0x47b93ffc) at gmain.c:935
> > #9  0x403e101b in gtk_main () at gtkmain.c:524
> > #10 0x0805e38f in main (argc=1, argv=0xbffed7f4) at main.c:423
> > #11 0x420174d9 in __libc_start_main () from /lib/i686/libc.so.6
> > (gdb) list
> > 1961	    tmp_list = gdk_default_filters;
> > 1962	  
> > 1963	  while (tmp_list)
> > 1964	    {
> > 1965	      filter = (GdkEventFilter *)tmp_list->data;
> > 1966	      if ((filter->function == function) && (filter->data == data))
> > 1967		return;
> > 1968	      tmp_list = tmp_list->next;
> > 1969	    }
> > 1970	  
> > 
> > 
> > It would be really nice with some help tracking this issue down since
> > it's become somewhat a showstopper for GNOME 1.4.1 just because of the
> > sheer amount of people reporting it.
> 
> I'll just follow up on this here.
> 
> I've been doing some more investigation into this matter with the help
> from a lot of very nice people (you know who you are - and beers are on
> me when we next meet) and I've been able to corner the beast further.
> 
> It seems that gdk_window_ref_from_xid() returns a window with garbage
> data. After looking at that more closely it is really
> gdk_window_lookup(), which again is a #define for gdk_xid_table_lookup()
> that returns bogus data.
> 
> This gives us the clue that it is the xid table that has been corrupted,
> or am I wrong here?
> 
> Example of a corrupted entry:
> 
> Breakpoint 1, gdk_window_ref_from_xid (xwin=56623105) at gwmh.c:341
> 341	  window = gdk_window_lookup (xwin);
> (gdb) b gdk_xid_table_lookup
> Breakpoint 2 at 0x405286b2: file gdkxid.c, line 64.
> (gdb) c
> Continuing.
> 
> Breakpoint 2, gdk_xid_table_lookup (xid=56623105) at gdkxid.c:64
> 64	  gpointer data = NULL;
> (gdb) n
> 66	  if (xid_ht)
> (gdb) n
> 67	    data = g_hash_table_lookup (xid_ht, &xid);
> (gdb) n
> 69	  return data;
> (gdb) p xid_ht
> $1 = (GHashTable *) 0x80eadd8
> (gdb) p *xid_ht
> $2 = {size = 163, nnodes = 149, frozen = 0, nodes = 0x81a4110, 
>   hash_func = 0x405286f0 <gdk_xid_hash>, 
>   key_compare_func = 0x40528700 <gdk_xid_compare>}
> (gdb) p xid
> $3 = 56623105
> (gdb) p &xid
> $4 = (XID *) 0xbffff3a0
> (gdb) n
> 70	}
> (gdb) n
> gdk_window_ref_from_xid (xwin=56623105) at gwmh.c:342
> 342	  if (!window)
> (gdb) p *window
> $5 = {user_data = 0x406952e8}
> (gdb) p *(GtkWidget*)0x406952e8
> $6 = {object = {klass = 0x406952e0, flags = 1080644320, ref_count =
> 136022416, 
>     object_data = 0x81b8990}, private_flags = 21232, state = 105 'i', 
>   saved_state = 64 '@', 
>   name = 0x406952f0 "\220\211\e\b\220\211\e\bðRi ðRi@Ðq\e\bÐq\e\b", 
>   style = 0x81b71d0, requisition = {width = 29136, height = 2075}, 
>   allocation = {x = 21248, y = 16489, width = 21248, height = 16489}, 
>   window = 0x81433c8, parent = 0x81433c8}
> (gdb) 
> 
> Does anyone have a clue how to find out why/when/who corrupts this hash
> table? I think this is maybe the way to proceed?
> 

Correcting the mailing list address. And one more question. If this
corrupts the xid hash table then is there a chance that the crashes
we've seen in applet_widget_construct() is the same case? I ask because
that's the only place in 1.4.x I can find a call to gdk_window_lookup()
besides the gwmh.c file.

Cheers
Kjartan




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]