[Bug 31824] Dapper: Adept takes multiple tries to start

[mornfall]

Public bug report changed:
https://launchpad.net/malone/bugs/31824

Task: ubuntu ept
       Assignee: Kubuntu Team => mornfall
         Status: Needs Info => Fix Released

Comment:
There were (again) more issues involved. One is the application/octet-stream hang (the more likely one) that seems to affect fair amount of installations. After upgrading to 1.91, these should go away and be replaced by an error dialog saying could not find mime type application/octet-stream. This is most probably not an adept bug and is harmless, albeit annoying. This will be hopefully fixed later. This is also the problem that would be fixed by removing the arguments in the Exec string of adept (most probably kdesu interaction). This bug also depends on order of packages in apt cache. Installing or removing packages changes this order, so that's why the bug went away when libqt-perl was installed. Any package would do in fact. The bug could also reappear on next update or installation/removal.

In a given system state, the above bug would be completely deterministic. Until you run apt-get update or install some package, it would consistently either work or hang every time.

Then, there was a race condition in adept debug output that would cause deadlock from time to time. Apparently, the deadlock is more likely to happen when running in kdesu due to output stream handling of kdesu. This problem should be fixed in 1.91 too.

This second problem is not deterministic. In a completely same configuration (running adept, killing adept, running adept, killing adept) it could happen in some tries and not happen in other tries. Apparently, this bug is also hardware-dependent, as it seems to not happen on my system (em64t, ht-enabled cpu) but does on others.

In either case, upgrading to 1.91 should fix these issues. If you happen to run into a situation where adept does not start on the first try, please extract the relevant part of your .xsession-errors, find out if adept process is running or not, if it is still running, attach gdb and get full backtrace (thread apply all bt). Then report the problem, the way you ran the program (sudo from terminal, kdesu from terminal, kdesu from kde menu, etc), the output and gdb output you managed to collect. You may file bugs either in KDE bugzilla at bugs.kde.org or here.

I will close this bug now, report any new issues in separate reports, thanks.