Le mercredi 05 mai 2010 à 14:13 +0200, Nicolai Stange a écrit :
> However, I've got the coredump out of our backups and here's the
> backtrace with debugging symbols:
> (gdb) up 3
> #3 gdk_window_queue (window=0x7f015f74ba60, item=0x7f01561cdcd0)
> at /build/buildd/gtk+2.0-2.12.12/gdk/x11/gdkgeometry-x11.c:1056
> 1056 /build/buildd/gtk+2.0-2.12.12/gdk/x11/gdkgeometry-x11.c: No such
> file or directory.
> in /build/buildd/gtk+2.0-2.12.12/gdk/x11/gdkgeometry-x11.c
> Current language: auto; currently c
> (gdb) p item
> $1 = (GdkWindowQueueItem *) 0x7f0165642e77
> (gdb) p *item
> Cannot access memory at address 0x7f0165642e77
>
> gdk/x11/gdkgeometry-x11.c:1056 with Debian Patches applied is within
> gdk_qindow_queue:
> GList *tmp_list = display_x11->translate_queue->head;
>
> while (tmp_list)
> {
> GdkWindowQueueItem *item = tmp_list->data;
> GList *next = tmp_list->next;
>
> /* an overflow-safe (item->serial < serial) */
> => if (item->serial - serial > (gulong) G_MAXLONG)
>
> The code for gdk_window_queue in GTK+ 2.18.9 is exactly the same.
> Maybe, you've got a guess about whether I should search for the problem
> within GTK or within my homebrew thunderbird build?I haven’t found any similar backtraces being reported, and this code hasn’t changed, and I don’t see anything obvious in the GTK+ history that would fix this. Looking further is like searching for a needle in a haystack. If you really want to understand what’s happening you should look for what put broken data in the queued events list. And this could well be something in Thunderbird. In all cases I can only recommend to not build Mozilla products yourself. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `- […] I will see what I can do for you.” -- Jörg Schilling
signature.asc
Description: This is a digitally signed message part
