Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#1566 closed defect (invalid)

Gajim crashes untill I run `unset DBUS_SESSION_BUS_ADDRESS'

Reported by: Dawid Gajownik Owned by: asterix
Priority: normal Milestone: 0.9.1
Component: None Version: 0.9.1
Severity: normal Keywords:
Cc: gajownik@… Blocked By:
Blocking: OS:



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:

I noticed that it runs fine if I type:


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

[y4kk0@X ~]$ rpm -qa | grep dbus
[y4kk0@X ~]$

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

Attachments (1)

threads_init.patch (530 bytes) - added by dkirov 11 years ago.
fixes gajim crush on fc4

Download all attachments as: .zip

Change History (7)

comment:1 Changed 11 years ago by nk

please read

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

comment:2 Changed 11 years ago by 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 (
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/".

(gdb) run
Starting program: /usr/bin/python
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/
#6  0x00ac84d6 in g_main_context_check () from /usr/lib/
#7  0x00ac87c3 in g_main_loop_run () from /usr/lib/
#8  0x041b3a46 in gtk_main () from /usr/lib/
#9  0x00e47db1 in init_gtk () from /usr/lib/python2.4/site-packages/gtk-2.0/gtk/
#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 "", 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

comment:3 Changed 11 years ago by nk

  • Resolution set to invalid
  • Status changed from new to closed

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?]

comment:4 Changed 11 years ago by dkirov

  • Milestone set to 0.9.1

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

Changed 11 years ago by dkirov

fixes gajim crush on fc4

comment:5 Changed 11 years ago by Dawid Gajownik

  • Cc gajownik@… added

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:


[y4kk0@X ~]$ gajim
Traceback (most recent call last):
  File "", line 1558, in ?
  File "/usr/share/gajim/src/common/", line 227, in migrate
pysqlite2.dbapi2.OperationalError: table jids already exists
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.4/", line 442, in __bootstrap
  File "/usr/lib/python2.4/", line 422, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/share/gajim/src/common/", line 227, in migrate
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
[y4kk0@X ~]$

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

Thanks for your time :-)

comment:6 Changed 11 years ago by 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 :)


Note: See TracTickets for help on using tickets.