Bug 307049 - kdialog each time appears after 25 seconds
Summary: kdialog each time appears after 25 seconds
Status: RESOLVED FIXED
Alias: None
Product: muon
Classification: Unclassified
Component: notifier (show other bugs)
Version: 1.3.1
Platform: Ubuntu Packages Linux
: NOR major (vote)
Target Milestone: ---
Assignee: Jonathan Thomas
URL: https://code.google.com/p/chromium/is...
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-19 14:42 UTC by kenorb
Modified: 2012-09-29 17:43 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 1.4.1


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kenorb 2012-09-19 14:42:18 UTC
When I'm using Chrome 18.0.1025.168 (Developer Build 134367 Linux) on Ubuntu 12.04, the KDialog takes around 25 seconds to show up!


Reproducible: Always

Steps to Reproduce:
1. Go to: https://code.google.com/p/chromium/issues/entry
2. Click on: Attach the file
3. Click on: Choose File
4. Problem: Nothing happens.
5. After 25 seconds KDialog appears.
6. It takes another 20-30 seconds to fully load (still you can't click anything).
7. After the whole 1 minute you can choose the file.




Expected Results:  
In Firefox (which doesn't uses KDialog) it works within few seconds.


Qt: 4.8.1
KDE Development Platform: 4.8.4 (4.8.4)
KDialog: 1.0

When executed manually the following command:
strace kdialog --attach=71303405 --title=Open File --getopenfilename /home/kenorb/Sites/x/sites/all/modules/contrib/simpletest_clone

It seems to stop on poll for exactly 25 seconds!

write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
poll([{fd=6, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=6, revents=POLLOUT}])
writev(6, [{"\225\24\31\0\32\0\300\5\1\0\0\0+\0\0\0\7\0\t\0\377\377\t\0\t\0\0\0\3648\0\0"..., 400}, {NULL, 0}, {"", 0}], 3) = 400
recvfrom(6, 0x7aef44, 4096, 0, 0, 0)    = -1 EAGAIN (Resource temporarily unavailable)
write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\21\0\0\0\20\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\f\0\0\0org.kde.kded\0", 17}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 161
poll([{fd=7, events=POLLIN}], 1, 25000) = 1 ([{fd=7, revents=POLLIN}])
recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\1\t\0\0\0\6\0\0\0=\0\0\0\6\1s\0\6\0\0\0:1.162\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 89
recvmsg(7, 0x7fff4ef79770, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\21\0\0\0k\0\0\0\1\1o\0\5\0\0\0/kded\0\0\0"..., 128}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 128
poll([{fd=7, events=POLLIN}], 1, 25000

Is there any sleep(25) or something? Why?
It happens every time to me when I'm trying to upload anything on any site in Chrome browser, but it also happens in other software using KDialog as well.

Qt: 4.8.1
KDE Development Platform: 4.8.5 (4.8.5)
KDialog: 1.0
Comment 1 Christoph Feck 2012-09-19 14:49:59 UTC
Please temporarily rename ~/.kde/share/apps/kfileplaces/bookmarks.xml and try again. You might have some remote places in the places panel that get stuck waiting for a connection.
Comment 2 kenorb 2012-09-19 15:02:06 UTC
I've moved the file. The file was re-created within few seconds after 'Choose file' click to default, but still it took KDialog 25 seconds to appear.
bookmarks.xml file seems to be default as it was.
Comment 3 Christoph Feck 2012-09-19 15:08:37 UTC
Could you try running "solid-hardware list details" in a Konsole, and check if it blocks for the same long time? Is "dbus-daemon" running for your current user?
Comment 4 kenorb 2012-09-19 15:11:50 UTC
Simulating the same command like as it was executed by Chrome (it's doing the same):
$ time kdialog --attach=56623340 --title="Open File" --getopenfilename /home/kenorb/Downloads/
kdialog(8234)/kdecore (K*TimeZone*): KSystemTimeZones: ktimezoned initialize() D-Bus call failed:  "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."

real	1m42.668s
user	0m0.496s
sys	0m0.088s
Time when kdialog was run and first attempt to click Cancel.

dbus-daemon is run for current user:

$ ps wuax | grep dbus-daemon
102        868  0.0  0.0  25064  2060 ?        Ss   13:41   0:00 dbus-daemon --system --fork --activation=upstart
kenorb    1955  0.0  0.0  26476  2400 ?        Ss   13:42   0:01 //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
kenorb    8247  0.0  0.0  13580   932 pts/6    S+   17:02   0:00 grep --color=auto dbus-daemon
Comment 5 kenorb 2012-09-19 15:27:10 UTC
strace gives me this:


8549  sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\21\0\0\0\20\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\f\0\0\0org.kde.kded\0", 17}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 161 <0.000015>
8549  poll([{fd=7, events=POLLIN}], 1, 25000) = 1 ([{fd=7, revents=POLLIN}]) <0.000061>
8549  recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\1\t\0\0\0\6\0\0\0=\0\0\0\6\1s\0\6\0\0\0:1.169\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 89 <0.000009>
8549  recvmsg(7, 0x7fff71c561e0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) <0.000010>
8549  sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\21\0\0\0k\0\0\0\1\1o\0\5\0\0\0/kded\0\0\0"..., 128}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 128 <0.000010>
8549  poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.020763>

Last <number> show the time spent in system calls.
poll() = 25 seconds
I've 4 of these in one run:
8549  poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.020763>
8549  poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.008094>
8549  poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.025128>
8549  poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.025123>
25 second each = 1 minute.
All are similar.
Comment 6 kenorb 2012-09-19 15:29:39 UTC
Problem with KDialog I had before the upgrade of kde-plasma.
But after the upgrade, I've similar problem with kde-plasma panel. It takes half a minute to react on clicks, but it didn't happen before the upgrade.
So it could be something in common.

Link:
https://bugs.kde.org/show_bug.cgi?id=307048
Comment 7 kenorb 2012-09-19 15:34:54 UTC
So the problem is related to DBus.
How do I diagnose while the dbus is run?

8758  recvmsg(7, 0x7fff53179c10, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) <0.000005>
8758  sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\21\0\0\0k\0\0\0\1\1o\0\5\0\0\0/kded\0\0\0\6\1s\0\f\0\0\0org.kde.kded\0\0\0\0\2\1s\0#\0\0\0org.freedesktop.DBus.Introspectable\0\0\0\0\0\3\1s\0\n\0\0\0Introspect\0\0\0\0\0\0", 128}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 128 <0.000010>
8758  poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.013023>
Comment 8 Christoph Feck 2012-09-19 15:50:52 UTC
I can only guess from seeing the parts you posted, that there is a kded module blocking the D-Bus system. Please try disabling kded modules as described at http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/

Probable candidates are network manager related modules, or anything that is related to package updates.
Comment 9 kenorb 2012-09-19 15:56:03 UTC
I've tried to restart dbus, but it didn't help.
While I wanted to kill it, it frozen my machine, so I had to reboot.

I don't know much about dbus, but I can see after clean reboot, something it's using debug resources much:
$ netstat -na | grep dbus | grep CONNECTED | wc -l
124

$ sudo netstat -nap | grep dbus | grep CONNECTED | awk '{print $8}' | sort | uniq -c
      2 1932/dbus-launch
     95 1933/dbus-daemon
      4 2490/gvfsd-trash
      2 2492/gvfsd-burn
     44 865/dbus-daemon

It's normal?
Comment 10 kenorb 2012-09-19 16:01:02 UTC
Thanks for your help, I'll try to find some workaround for it.
Comment 11 kenorb 2012-09-20 10:33:23 UTC
Related dbus bug:
https://bugs.freedesktop.org/show_bug.cgi?id=55136
Comment 12 kenorb 2012-09-20 11:55:54 UTC
The other interesting thing I found, that actually KDialog sending the empty message!

As you can see before: msg_name(0)=NULL

[pid 15820] sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\21\0\0\0k\0\0\0\1\1o\0\5\0\0\0/kded\0\0\0\6\1s\0\f\0\0\0org.kde.kded\0\0\0\0\2\1s\0#\0\0\0org.freedesktop.DBus.Introspectable\0\0\0\0\0\3\1s\0\n\0\0\0Introspect\0\0\0\0\0\0", 128}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 128

When I'm monitoring my dbus socket, it showed as:
$ dbus-monitor --address unix:path=/var/run/dbus/system_bus_socket --monitor

signal sender=org.freedesktop.DBus -> dest=(null destination) serial=31 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.71"
   string ""
   string ":1.71"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=32 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.71"
   string ":1.71"
   string ""

Destination is NULL.

This is other example how it suppose to look:
signal sender=org.freedesktop.DBus -> dest=:1.66 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.66"

Maybe that's the reason of timeout?
Comment 13 Christoph Feck 2012-09-20 20:04:11 UTC
Still looks like an issue with a kded module (see comment #8). Without trying which one you need to disable, it is nearly impossible to debug.
Comment 14 Christoph Feck 2012-09-20 20:06:06 UTC
Note that KDialog itself does not use D-Bus itself; the problem is very likely in the solid libraries or runtime system. Which makes me wondering: Are you actually running a full KDE session, or do you use KDE software inside a different desktop?
Comment 15 kenorb 2012-09-21 07:47:06 UTC
I'm using full KDE plasma desktop.
Comment 16 kenorb 2012-09-21 07:49:00 UTC
Before I was using Unity, but it was even worse, it was freezing all the time, crashing, lots of missing options, just a nightmare. So KDE plasma is kind of relief for me, but it's still not perfect.
Comment 17 kenorb 2012-09-21 09:50:27 UTC
Current follow-up:
https://bugs.launchpad.net/ubuntu/+source/kde-baseapps/+bug/1053910
Comment 18 Christoph Feck 2012-09-21 10:22:41 UTC
So did you try disabling some kded modules? I know it is a tedious task, but I don't see any option right now. Filing more bug reports in different directions won't help if you do not follow the advices you get from there.
Comment 19 kenorb 2012-09-24 09:13:18 UTC
Thanks, I'm trying it now.
Because the panel doesn't work, I've to go to Settings from the command line:
$ systemsettings

As advised:
"Disable kded4 modules in System Settings > Startup and Shutdown > Service Manager."
I'm going to Startup and Shutdown, everything is fine till that moment.
When clicking on 'Service Manager', the window is freezing for around 1 minute and then I've the error:
"Unable to contact KDED."
Then all the Startup Services are gray/disabled and 'Not running'. So I can't change anything.

So I'm disabling all the services manually by renaming all files to something else:
$ cd /usr/share/kde4/services/kded
$ sudo rename 's/.desktop/.desktop.disabled/' *.desktop
$ kbuildsycoca4
Comment 20 kenorb 2012-09-24 09:23:24 UTC
And finally:
$ killall -HUP kdeinit4
then my whole session was killed, killing all my processes, but after testing with disabled all kde modules it works, kdialog appears in less than 1 second (including loading) for 'Choose File' web widgets and KDE desktop-plasma panel is clickable again.
I'll do some more tests and I'll find the broken module. Thanks again.
Comment 21 kenorb 2012-09-24 09:26:22 UTC
E.g.:
Enabling all modules starting with letter 'k':
$ sudo rename 's/.disabled//' k*.desktop.disabled
$ killall -HUP kdeinit4
Comment 22 kenorb 2012-09-24 11:57:40 UTC
It looks line muon-notifier is the one which breaks kdialog functionality and plasma-desktop panel.
File: muon-notifier.desktop
Whatever it's.

Renaming /usr/share/kde4/services/kded/muon-notifier.desktop
and restarting kdeinit4 solve the problem.

$ dpkg -l | grep muon-notifier
ii  muon-notifier                          1.3.1-0ubuntu2                                                          update notifier for KDE
Comment 23 kenorb 2012-09-24 12:11:31 UTC
I'm confused also what's the policy and where I should report the bug of kde muon-notifier.
Here at bugs.kde.org directly, or at bugs.launchpad.net/ubuntu/+source/muon.
Also by creating a new bug, or following the current one.
As I understand, the policy on launchpad.net is that I should create always the new bugs.
Comment 24 kenorb 2012-09-24 12:17:07 UTC
Enabling muon-notifier.desktop service creating following process:
kenorb   11328  0.0  0.3 131788 12392 ?        S    13:55   0:00 /usr/bin/python /usr/share/kde4/apps/muon-notifier/releasechecker

When killing the process manually, it seems that everything is back to normal.

When running it manually again using the same command line, I've this error:

 /usr/bin/python /usr/share/kde4/apps/muon-notifier/releasechecker
Unhandled exception in thread started by <bound method MetaReleaseCore.download of <UpdateManager.Core.MetaRelease.MetaReleaseCore object at 0x228f9d0>>
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/UpdateManager/Core/MetaRelease.py", line 262, in download
    uri=urllib2.urlopen(req, timeout=20)
  File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 400, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 418, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 378, in _call_chain
    result = func(*args)
...
  File "/usr/lib/python2.7/socket.py", line 447, in readline
    data = self._sock.recv(self._rbufsize)
socket.error: [Errno 104] Connection reset by peer

Probably, because I'm behind the proxy.
Comment 25 Jonathan Thomas 2012-09-25 23:35:27 UTC
Git commit c67667633ada69b6feee0216de4da03de963a82c by Jonathan Thomas.
Committed on 26/09/2012 at 01:33.
Pushed by jmthomas into branch '1.4'.

Catch all exceptions coming from MetaReleaseChecker and don't let them hang the process.

*Grumble I hate python Grumble*
FIXED-IN:1.4.1

M  +14   -10   kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/c67667633ada69b6feee0216de4da03de963a82c
Comment 26 Jonathan Thomas 2012-09-25 23:35:28 UTC
Git commit ae8bcd2062e0285d204f53fbca3de0a024c3648b by Jonathan Thomas.
Committed on 26/09/2012 at 01:33.
Pushed by jmthomas into branch 'master'.

Catch all exceptions coming from MetaReleaseChecker and don't let them hang the process.

*Grumble I hate python Grumble*
FIXED-IN:1.4.1

M  +14   -10   kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/ae8bcd2062e0285d204f53fbca3de0a024c3648b
Comment 27 Jonathan Thomas 2012-09-25 23:35:28 UTC
Git commit abeacf1a952813f716b079d40189f1980692ebfc by Jonathan Thomas.
Committed on 26/09/2012 at 01:33.
Pushed by jmthomas into branch 'qapt2'.

Catch all exceptions coming from MetaReleaseChecker and don't let them hang the process.

*Grumble I hate python Grumble*
FIXED-IN:1.4.1

M  +14   -10   kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/abeacf1a952813f716b079d40189f1980692ebfc
Comment 28 kenorb 2012-09-26 08:20:49 UTC
I've updated this script, but it seems it still failing when running it:

$ python -d /usr/share/kde4/apps/muon-notifier/releasechecker
Unhandled exception in thread started by <bound method MetaReleaseCore.download of <UpdateManager.Core.MetaRelease.MetaReleaseCore object at 0xd1e750>>
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/UpdateManager/Core/MetaRelease.py", line 262, in download
    uri=urllib2.urlopen(req, timeout=20)
  File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 400, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 418, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 378, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1207, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1180, in do_open
    r = h.getresponse(buffering=True)
  File "/usr/lib/python2.7/httplib.py", line 1030, in getresponse
    response.begin()
  File "/usr/lib/python2.7/httplib.py", line 407, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python2.7/httplib.py", line 365, in _read_status
    line = self.fp.readline()
  File "/usr/lib/python2.7/socket.py", line 447, in readline
    data = self._sock.recv(self._rbufsize)
socket.error: [Errno 104] Connection reset by peer

Even there is try/except
Comment 29 Jonathan Thomas 2012-09-26 11:25:52 UTC
Could you try replacing "except Exception, e:" with "except BaseException, e:"? Apparently python's Exception class is only for non language-defined exceptions. :/ (Unlike Java exceptions... Another reason to hate python)
Comment 30 kenorb 2012-09-26 12:08:31 UTC
I've tried, but it doesn't change anything.
Maybe because it's a separate thread?

Problem is happening in File "/usr/lib/python2.7/dist-packages/UpdateManager/Core/MetaRelease.py", line 262
So the exception was caught by  /usr/lib/python2.7/socket.py
socket.error: [Errno 104] Connection reset by peer

python -m trace -c -t   /usr/share/kde4/apps/muon-notifier/releasechecker
MetaRelease.py(160):         try:
MetaRelease.py(161):             if os.path.getsize(self.METARELEASE_FILE) == 0:
 --- modulename: genericpath, funcname: getsize
genericpath.py(49):     return os.stat(filename).st_size
MetaRelease.py(165):         return True
MetaRelease.py(137):         thread.start_new_thread(self.download, ())
releasechecker(35):         while metaRelease.downloading:
releasechecker(36):             time.sleep(1)
Unhandled exception in thread started by <bound method MetaReleaseCore.download of <UpdateManager.Core.MetaRelease.MetaReleaseCore object at 0x1a44fd0>>
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/UpdateManager/Core/MetaRelease.py", line 262, in download
    uri=urllib2.urlopen(req, timeout=20)
  File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 400, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 418, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 378, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1207, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1180, in do_open
    r = h.getresponse(buffering=True)
  File "/usr/lib/python2.7/httplib.py", line 1030, in getresponse
    response.begin()
  File "/usr/lib/python2.7/httplib.py", line 407, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python2.7/httplib.py", line 365, in _read_status
    line = self.fp.readline()
  File "/usr/lib/python2.7/socket.py", line 447, in readline
    data = self._sock.recv(self._rbufsize)
socket.error: [Errno 104] Connection reset by peer
releasechecker(35):         while metaRelease.downloading:
releasechecker(36):             time.sleep(1)
releasechecker(35):         while metaRelease.downloading:
releasechecker(36):             time.sleep(1)
releasechecker(35):         while metaRelease.downloading:
releasechecker(36):             time.sleep(1)

So basically script is ignoring 'Unhandled exception' and script is continuing to check the release every second.

Something similar which I found:
http://askubuntu.com/questions/130267/cant-update-to-ubuntu-12-04-on-11-10
Comment 31 Jonathan Thomas 2012-09-26 16:04:42 UTC
Git commit 6d9581b2984c89e0ed91a27a205b345e67198c01 by Jonathan Thomas.
Committed on 26/09/2012 at 18:01.
Pushed by jmthomas into branch '1.4'.

Exceptions that MetaReleaseCore throw during a download happen in a separate thread, so we can't catch them.

The root cause of the IOError seems to be the existence of a proxy, and it appears that UpdateManager has a proxy init function. (Poor design on UpdateManager's part...)
This should fix the root cause of this bug, but I fear for other exceptions that could be thrown that MetaReleaseCore won't catch for us...
I'll commit a separate fix to make our KProcess call to releasechecker non-blocking.

M  +11   -14   kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/6d9581b2984c89e0ed91a27a205b345e67198c01
Comment 32 Jonathan Thomas 2012-09-26 16:04:45 UTC
Git commit f4821f9050ccd4e56fde5cd2f13530bf5468f4c1 by Jonathan Thomas.
Committed on 26/09/2012 at 18:01.
Pushed by jmthomas into branch 'master'.

Exceptions that MetaReleaseCore throw during a download happen in a separate thread, so we can't catch them.

The root cause of the IOError seems to be the existence of a proxy, and it appears that UpdateManager has a proxy init function. (Poor design on UpdateManager's part...)
This should fix the root cause of this bug, but I fear for other exceptions that could be thrown that MetaReleaseCore won't catch for us...
I'll commit a separate fix to make our KProcess call to releasechecker non-blocking.

M  +11   -14   kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/f4821f9050ccd4e56fde5cd2f13530bf5468f4c1
Comment 33 Jonathan Thomas 2012-09-26 16:04:45 UTC
Git commit 4028651c70dc854965c2c994074f0798690b516d by Jonathan Thomas.
Committed on 26/09/2012 at 18:01.
Pushed by jmthomas into branch 'qapt2'.

Exceptions that MetaReleaseCore throw during a download happen in a separate thread, so we can't catch them.

The root cause of the IOError seems to be the existence of a proxy, and it appears that UpdateManager has a proxy init function. (Poor design on UpdateManager's part...)
This should fix the root cause of this bug, but I fear for other exceptions that could be thrown that MetaReleaseCore won't catch for us...
I'll commit a separate fix to make our KProcess call to releasechecker non-blocking.

M  +11   -14   kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/4028651c70dc854965c2c994074f0798690b516d
Comment 34 Jonathan Thomas 2012-09-26 16:07:20 UTC
(Sorry about the duplication of the mail, I pushed the commit to three branches and the commit hook picked up on all three)

Anyways, this should fix the "IOError due to proxy" issue. To really "fix" this I'll make the invocation of releasechecker asynchronous, so that shoddy programming on UpdateManager's part doesn't block kded until UpdateManager times out.
Comment 35 Jonathan Thomas 2012-09-26 16:47:12 UTC
Git commit 058d412f365744ce0a3b4c513385486390ca4ea5 by Jonathan Thomas.
Committed on 26/09/2012 at 18:45.
Pushed by jmthomas into branch '1.4'.

Asynchronize the process to check for a new release.
If UpdateManager hangs due to a bug/poor design on their part, we can be stuck for up to 25 seconds, hanging all of KDED along with us.

M  +21   -5    kded/MuonNotifier.cpp
M  +5    -2    kded/MuonNotifier.h
M  +0    -24   kded/distupgradeevent/distupgradeevent.cpp
M  +0    -3    kded/distupgradeevent/distupgradeevent.h
M  +1    -0    kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/058d412f365744ce0a3b4c513385486390ca4ea5
Comment 36 Jonathan Thomas 2012-09-26 16:47:12 UTC
Git commit 90bd4c2d893c76bcae539e33283cb1a10b2661ec by Jonathan Thomas.
Committed on 26/09/2012 at 18:45.
Pushed by jmthomas into branch 'master'.

Asynchronize the process to check for a new release.
If UpdateManager hangs due to a bug/poor design on their part, we can be stuck for up to 25 seconds, hanging all of KDED along with us.

M  +21   -5    kded/MuonNotifier.cpp
M  +5    -2    kded/MuonNotifier.h
M  +0    -24   kded/distupgradeevent/distupgradeevent.cpp
M  +0    -3    kded/distupgradeevent/distupgradeevent.h
M  +1    -0    kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/90bd4c2d893c76bcae539e33283cb1a10b2661ec
Comment 37 Jonathan Thomas 2012-09-26 16:47:16 UTC
Git commit 5029d161876711807f02943686d2383c01861c35 by Jonathan Thomas.
Committed on 26/09/2012 at 18:45.
Pushed by jmthomas into branch 'qapt2'.

Asynchronize the process to check for a new release.
If UpdateManager hangs due to a bug/poor design on their part, we can be stuck for up to 25 seconds, hanging all of KDED along with us.

M  +21   -5    kded/MuonNotifier.cpp
M  +5    -2    kded/MuonNotifier.h
M  +0    -24   kded/distupgradeevent/distupgradeevent.cpp
M  +0    -3    kded/distupgradeevent/distupgradeevent.h
M  +1    -0    kded/distupgradeevent/releasechecker

http://commits.kde.org/muon/5029d161876711807f02943686d2383c01861c35