GNOME.org
 

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

Used the wrong list address in this the first time.

Cheers
Kjartan
--- Begin Message --- 
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?

Cheers
Kjartan
(Who said 1.4.x is unmaintained? Hah!)

--- End Message ---
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]