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