Bug 7261

I try to get a useful backtrace for this problem, but it seems it's not so easy.
I can still reproduce it with recent git snap, but compiling both libX11 and
libxcb with debug symbols and frame pointers doesn't help to get a valid
backtrace I am affraid. I wonder did I miss something ?

--------
[morgoth@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)
--------

Hmmm, I am start to affraid I am too stupid for that. I installed ethereal and
set it to captude data from 'lo' interface of coz starting X without nolisten
option (Also set it in gdm)

But ethereal doesn't capture anything. Sends ping to lo capture it correctly
then  program works fine, but there was nothing else than my ping.

This cause me a lot of troubles, but I found solution for gdb backtrace problem.
Snooping the gdb cvs I locate the fix:

2005-12-10  Daniel Jacobowitz  <dan@codesourcery.com>

    PR tdep/2029
    Suggested by Till Straumann <strauman@slac.stanford.edu>:
    * rs6000-tdep.c (skip_prologue): Update check for later mtlr
    instructions.  Handle PIC bcl.

And this one gives me a better result.

--------
#0  _XIOError (dpy=0x101bef90) at XlibInt.c:2924
#1  0x0e83ed0c in _XReply (dpy=0x101bef90, rep=0x7fed4048, extra=0, discard=0)
at xcl/io.c:297
#2  0x0e813b20 in XListFonts (dpy=0x101bef90, pattern=0x7fed40f8
"-*-fixed-medium-r-*-*-16-*-ISO8859-1", maxNames=<value optimized out>,
    actualCount=0x7fed4098) at FontNames.c:60
#3  0x0e875510 in get_font_name (oc=<value optimized out>, pattern=0xe7bfa28
"|`\033x\220\037") at omGeneric.c:525
#4  0x0e875a1c in parse_fontdata (oc=0x10366750, font_set=0x103694cc,
font_data=0x1035aba0, font_data_count=1, name_list=0x1035b550, name_list_count=2,
    class=C_PRIMARY, font_data_return=0x7fed4260) at omGeneric.c:839
#5  0x0e876a2c in create_oc (om=0x103668f0, args=<value optimized out>,
num_args=<value optimized out>) at omGeneric.c:1182
#6  0x0e822874 in XCreateOC (om=0x101bef90) at OCWrap.c:53
#7  0x0e814594 in XCreateFontSet (dpy=<value optimized out>,
base_font_name_list=0x30697a5c "-*-fixed-medium-r-*-*-16-*,-*-*-medium-r-*-*-16-*",
    missing_charset_list=0x7fed43dc, missing_charset_count=0x7fed43d8,
def_string=0x0) at FSWrap.c:185
#8  0x3022b270 in QInputContext::setComposePosition () from
/usr/qt/3/lib/libqt-mt.so.3
#9  0x3022b634 in QInputContext::QInputContext () from /usr/qt/3/lib/libqt-mt.so.3
#10 0x30242e8c in QWidget::createInputContext () from /usr/qt/3/lib/libqt-mt.so.3
#11 0x30215980 in QApplication::x11ProcessEvent () from /usr/qt/3/lib/libqt-mt.so.3
#12 0x0e4911c0 in X11TrayIcon::enterEvent () from
/usr/bin/../share/kadu/modules/x11_docking.so
#13 0x30323fa8 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#14 0x3027ba60 in QApplication::internalNotify () from /usr/qt/3/lib/libqt-mt.so.3
#15 0x3027ca3c in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#16 0x3027dc9c in qt_dispatchEnterLeave () from /usr/qt/3/lib/libqt-mt.so.3
#17 0x30216010 in QApplication::x11ProcessEvent () from /usr/qt/3/lib/libqt-mt.so.3
#18 0x30227874 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#19 0x30294a04 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#20 0x302947dc in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x3027b350 in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#22 0x100db6b4 in main ()
--------

I hope it's OK this time.

Also I have a small update to this report. After the gdb patch work I was a
little soprised because I wasn't able to easily reproduce this bug and it seems
the starting kadu do not make it crash when I move the mouse pointer overthe
tray icon.

When the program is offline and someone leave a message the kadu after start
change it's icon (Normaly it's a small sun logo) to blinking envelope and
display some notification text above it. It seems this is required (Or make the
crash more frequent as I say sometimes it works fine) to reproduce this crash,
if I move the mouse pointer over it it makes kadu to crash.

OK, stupid me :/ I completly forgot that I need to run kadu with DISPLAY ... no
comments.

Created attachment 5996 [details]
Ethereal log for kadu crash

This log is captured in case when kadu fails when I move the mouse over it.

Created attachment 5997 [details]
Ethereal log for working kadu

This one is grabbed when kadu works fine. I simply start it, move mouse pointer
over the tray area and quit it.

Any news about that ?

Ping ?

This turned out to be an XCB bug.

morgoth has tested my fix, so I've pushed it.