Gajim crashes untill I run `unset DBUS_SESSION_BUS_ADDRESS'

[Dawid Gajownik]

Hi!

Gajim 0.9.1 was in Fedora Extras development repository for a while and I wanted to updated it also in Fedora Extras 4 repo. Unfortunately, it craches on startup:

http://img51.imageshack.us/img51/8489/gajimcrash3zw.png

I noticed that it runs fine if I type:

[y4kk0@X ~]$ echo $DBUS_SESSION_BUS_ADDRESS
unix:abstract=/tmp/dbus-FZMSUuFYoa,guid=25b8f343e61875594c675027c2f09b00
[y4kk0@X ~]$ unset DBUS_SESSION_BUS_ADDRESS

I was able to reproduce this on two computers (Fedora Core 4) and new, clean system accounts.

[y4kk0@X ~]$ rpm -qa | grep dbus
dbus-python-0.33-3.fc4.1
dbus-glib-0.33-3.fc4.1
dbus-x11-0.33-3.fc4.1
dbus-0.33-3.fc4.1
[y4kk0@X ~]$

Gajim 0.8.2 works fine, though. BTW can you disable showing email addresses in trac? I don't like spam :P

[nk]

please read http://trac.gajim.org/wiki/ReportingSegfault

if we could easily customize trac we would show the above link as well as hide the emails. atm both are trac limitations

[Dawid Gajownik]

I'm really sorry for my lame bug report. I had been searching through the wiki pages about debuging gajim but I did not find anything. It was really late and I have missed this link ;-)

Here's the backtrace:

[y4kk0@X src]$ gdb python
GNU gdb Red Hat Linux (6.3.0.0-1.84rh)
Copyright 2004 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 "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run gajim.py
Starting program: /usr/bin/python gajim.py
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x680000
[Thread debugging using libthread_db enabled]
[New Thread -1208625472 (LWP 7345)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208625472 (LWP 7345)]
0x0020d47e in PyErr_Occurred () at Python/errors.c:71
71      {
(gdb) bt
#0  0x0020d47e in PyErr_Occurred () at Python/errors.c:71
#1  0x0019c860 in PyObject_Cmp (o1=0x269420, o2=0x269420, result=0x0) at Objects/abstract.c:41
#2  0x005eb0f3 in __pyx_f_13dbus_bindings_cmessage_function_handler (__pyx_v_connection=0x0,
    __pyx_v_msg=0x0, __pyx_v_user_data=0xb7a1524c) at dbus_bindings.c:495
#3  0x05c7d2a5 in dbus_connection_dispatch (connection=0x94dff30) at dbus-connection.c:3495
#4  0x004ae307 in message_queue_dispatch (source=0x0, callback=0, user_data=0x0) at dbus-gmain.c:108
#5  0x00ac54ce in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#6  0x00ac84d6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#7  0x00ac87c3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#8  0x041b3a46 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#9  0x00e47db1 in init_gtk () from /usr/lib/python2.4/site-packages/gtk-2.0/gtk/_gtk.so
#10 0x001fd891 in PyEval_EvalFrame (f=0x900c84c) at Python/ceval.c:3531
#11 0x001feef8 in PyEval_EvalCodeEx (co=0xb7b836e0, globals=0xb7f34824, locals=0x0, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2730
#12 0x001ff228 in PyEval_EvalCode (co=0x0, globals=0x0, locals=0x0) at Python/ceval.c:484
#13 0x0021b55a in run_node (n=Variable "n" is not available.
) at Python/pythonrun.c:1265
#14 0x0021c7d2 in PyRun_SimpleFileExFlags (fp=Variable "fp" is not available.
) at Python/pythonrun.c:860
#15 0x0021d269 in PyRun_AnyFileExFlags (fp=0x8fd3008, filename=0xbf87770c "gajim.py", closeit=1,
    flags=0xbf876d14) at Python/pythonrun.c:664
#16 0x0022316d in Py_Main (argc=1, argv=0xbf876de4) at Modules/main.c:484
#17 0x080485ba in main (argc=0, argv=0x0) at Modules/python.c:23
(gdb) q
The program is running.  Exit anyway? (y or n) y
[y4kk0@X src]$

Platform: i386

OS: Fedora Core 4

[nk]

3rd frame is dbus

it's dbus problem from what I can tell. good luck [I propose you use latest versions of dbus and perhaps notif-daemon?]

[dkirov]

I installed fc4 as well as gajim-0.9.1-1 (gajim-remote disabled).

Dbus executes threads_init, we do it too and this causes the segfault. We had the same segfault with dbus 0.23, maybe fedora still keep some 0.23 code with 0.33. This patch prevents the segfault and you can be sure that this will not happen anymore in future gajim releases, because we don't use threads in svn. Cheers.

-- btw. fc4 looks awsome, my last experience was with rh9

[dkirov]

fixes gajim crush on fc4

[Dawid Gajownik]

I installed fc4 as well as gajim-0.9.1-1 (gajim-remote disabled).

It was the only workaround I could do :(

Thanks for the patch. Now gajim runs without a problem with D-BUS. Unforunately, it crashes on logs migration:

http://img392.imageshack.us/img392/5246/gui7pe.png

Traceback:

[y4kk0@X ~]$ gajim
Traceback (most recent call last):
  File "gajim.py", line 1558, in ?
    m.migrate()
  File "/usr/share/gajim/src/common/migrate_logs_to_dot9_db.py", line 227, in migrate
    self.con.commit()
pysqlite2.dbapi2.OperationalError: table jids already exists
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
    self.run()
  File "/usr/lib/python2.4/threading.py", line 422, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/share/gajim/src/common/migrate_logs_to_dot9_db.py", line 227, in migrate
    self.con.commit()
ProgrammingError: SQLite objects created in a thread can only be used in that same thread.The object was created in thread id -1208998208 and this is thread id -1218786384

[y4kk0@X ~]$ rpm -q python-sqlite2 sqlite
python-sqlite2-2.0.7-1.fc4
sqlite-3.1.2-3
[y4kk0@X ~]$

gajim-0.9.1 with disabled D-BUS support works fine, though.

Thanks for your time :-)

[dkirov]

It is very good that you find it, because the crash happens in svn version too. We'll fix it soon, but I think gajim-0.9.1-1 with gajim-remote disabled is the best for fedora. Mostly because the fix will need some time of testing and it is not a good idea to apply patches which are not 100% approved to work :)

Regards