On Thu, Sep 27, 2012 at 11:57:06AM +0200, intrigeri wrote:
> anonym wrote (27 Sep 2012 09:38:32 GMT) :
> > This was in Tails built from feature/multikernel.
>
> Thank you. I updated the ticket accordingly. So, next step is: somehow
> fix our USB installer vs. the 686-pae kernel. I'm not committing to do
> it any time soon.
After some gdb lifting, I got a stack trace mentioning
`_dbus_watch_invalidate`. This lead me to find this pretty old blog post
<
http://abandonedwig.info/blog/2009/03/dbus-and-threads.html> mentioning
that these stack traces were usually because of locking issues. It also
mentions that asking DBus to properly handle multiple threads is as
simple as running `dbus_thread_init_default()`
<
http://dbus.freedesktop.org/doc/api/html/group__DBusThreads.html#ga33b6cf3b8f1e41bad5508f84758818a7>
Unfortunately, while it looks fairly easy to do from Python when using
GLib, according to the answers on this page
<
http://stackoverflow.com/questions/6379553/calling-dbus-python-inside-a-thread>,
I have not been able to find a way to easily do something similar for
the Python DBus Qt bindings.
So my hack have been to add a call to `dbus_thread_init_default()` in
the initialization of the Python `dbus` module. And it looks like it
solve the issue. I have not been able to get the installer to crash
after installing the modified `python-dbus` package. From what I can
read from the documentation, except a performance hit, there should be
no other downsides to it.
The binary `python-dbus` package is fairly small (226 kB) and at this
time, it's a patch I feel we can carry on.
It's far from ideal, but it looks like there is very few users of the
Python Qt DBus binding. And our installer is hackish already... which
unfortunately tend to lead to more hacks. :(
What's your opinion? Should I proceed in adding a custom `python-dbus`
to the multikernel branch?
--
Ague
