Re: Loads of crashes in the panel / gwmh.c (gnome-core 1.4.x)
- From: Kjartan Maraas <kmaraas online no>
- To: gnome-devel-list gnome org
- Cc: desktop-devel-list gnome org, GNOME Hackers <gnome-hackers gnome org>
- Subject: Re: Loads of crashes in the panel / gwmh.c (gnome-core 1.4.x)
- Date: 06 Aug 2002 14:18:44 +0200
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]