[Xcb] XCB enabled libX11 and tray

[morgoth6 at box43.pl]

Hell[o]

Oups, it seems I send my last e-mail as a private one to Jamey ... sorry

--------

First as promised bugreport is filled at https://bugs.freedesktop.org/show_bug.cgi?id=7261

> Kadu's debug symbols won't help me, so you don't need to bother. I think
> GDB ought to give you good enough results without any debugging symbols
> really; but it would be better to have them for libX11 especially. Try
> first without recompiling so you can get the results to me faster. :-)

OK, sorry about the delay I simply was quite busy today. Anyway I give a try to get a backtrace without success I am afraid. Generaly I am not much experienced with gdb but I guess this should be enough to get backtrace. Right ?

--------
[morgoth at pegasos ~]$ gdb -d /var/portage/libX11-9999/work/libX11-9999/
/usr/bin/kadu
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-unknown-linux-gnu"...(no debugging symbols
found)
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) break _XIOError
Function "_XIOError" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (_XIOError) pending.
(gdb) run -X
Starting program: /usr/bin/kadu -X
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 813422160 (LWP 22624)]
Breakpoint 2 at 0xe8365ec: file XlibInt.c, line 2924.
Pending breakpoint "_XIOError" resolved
[New Thread 825029856 (LWP 22627)]
[New Thread 833418464 (LWP 22628)]
[Thread 833418464 (zombie) exited]
[Switching to Thread 813422160 (LWP 22624)]

Breakpoint 2, _XIOError (dpy=0x101bef90) at XlibInt.c:2924
2924        dpy->flags |= XlibDisplayIOError;
(gdb) bt
#0  _XIOError (dpy=0x101bef90) at XlibInt.c:2924
#1  0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#2  0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#3  0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#4  0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#5  0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#6  0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#7  0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#8  0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#9  0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#10 0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#11 0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#12 0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#13 0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#14 0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#15 0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#16 0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#17 0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#18 0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#19 0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#20 0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#21 0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#22 0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#23 0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#24 0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
#25 0x0e8365d8 in _XIOError (dpy=0x101bef90) at XlibInt.c:2923
Previous frame inner to this frame (corrupt stack?)
(gdb)
--------

It seems pc is identical for all stack. Sigh.

> I don't think so. I'm pretty confident that this code is endianness
> clean, though I admit it's a lot less tested on non-x86. :-) I doubt any
> other architecture-specific thing is the cause either. But it's a good
> piece of information for me to keep in mind, just in case.

Gr8.

> Both parts are vague: I don't have enough information yet. The Ethereal
> and GDB traces I asked for should be particularly informative.

The backtrace seems to be problematic a little. Have you any hints about that ?

And about Ethereal give me a few minutes more. It's almost compiledhere.

> By the way, are you using XIM (X Input Methods) to input characters that
> your keyboard doesn't have? Checking what calls _XIOError reminded me
> that the XIM code paths in my libX11 are probably completely untested.

Hmmmm, I don't I guess.

---- Marcin 'Morgoth' Kurek ----