Threading problems in WinDBus

Olivier Hochreutiner olivier.hochreutiner at gmail.com
Sat Jul 7 02:12:34 PDT 2007


> Hmm. I messed around with dbus-cxx a bit, but I seem to have a different
> version than yours or something, it doesn't look simple to get your test
> case going on my system.
>
> If you can make a simple compilable test case that is C or uses stock
> dbus-c++ I can download, then I can poke at this without a large time
> investment.

Well yes, sorry, I did a modif I did not push back yet. Can you try
Paolo's example ? I could reproduce (although he couldn't) with
THREADS == 1 (see his post).

> It looks an awful lot like thread locks just aren't present in your
> program, though why that is I don't know, if threads are initialized.

Well, threads are initialized (_init_threading_default() calls
dbus_thread_init_default()).

> It isn't surprising that verbose output prevents the bugs, since it
> effectively puts in a bunch of pauses. The verbose output is much slower
> than most other things libdbus would be doing.

Well so enabling verbose mode is kind of a workaround ? :-)

> You might want to break on the dbus thread functions like
> _dbus_mutex_lock and step through them in a debugger, to see which
> implementation is being used (_dbus_mutex_lock should end up calling
> _dbus_pthread_mutex_lock on linux for example). This is just to be sure
> there are locks at all, before debugging how the locking is messed up.

I'll check that.

> With that established another strategy is to add more and more
> assertions to libdbus to try to break things earlier, to try and narrow
> down the exact point where it goes wonky.

I can try that, although I am not quite familiar with D-Bus internals...

Thanks for your help.

Olivier


More information about the dbus mailing list