On Sat, Nov 6, 2010 at 12:35 AM, Thiago Macieira <[email protected]> wrote: > On Friday, 5 de November de 2010 18:54:43 Dawit A wrote: >> > Can you give me a "thr apply all bt full" of this lockup? >> >> I guess I would need to recompile both qt and dbus in debug mode for >> this... In the meantime, I have attached what you requested with what >> I have now. The freeze occurred where you see the CTRL + C... > > Just QtDBus and libdbus-1. However, Thread 1 is stopped at poll(), which > usually indicates that all locks have been acquired and the socket has been > written to (or it's waiting to write).
Ok, I will try to compile those with debug support. Though the entry points maybe different, all the freezes I see end up exactly at the same place... dbus doing a poll. Always... > Can you measure this lockup? Does it take 25 seconds, exactly? If it does, it > looks more likely that the call was sent and udisks didn't reply. Indeed. It does take exactly 25 secs ; so I guess that is the default timeout for the dbus call. It is curious that you only see this from GUI applications though. No matter what I do I cannot reproduce it from the command line tools like 'solid-hardware'...
