My plasma-desktop is critically sluggish, panel and kdialog reacts after few minutes because of dbus Timeout problem
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
D-Bus |
Won't Fix
|
High
|
|||
Muon |
Fix Released
|
High
|
|||
muon (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
I've been sent from pillar to post from almost few days, spent already few days investigating my Ubuntu slugginess right just after install, so I hope this report is now in the right place. I don't have time for this, I really need to work, instead of spending days fighting with simple usage of Ubuntu and reporting the bugs and receiving messages like 'this is not a bug of x', 'this is not a bug of y'.
The bug affects affect in general plasma-desktop on Ubuntu.
Some examples:
Using Chrome which uses KDialog, any file upload takes minutes.
KDialog timeouts after 25 seconds 4 times, makes it the whole minute to show up.
Steps to Reproduce:
1. Go to: https:/
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.
Other bugs which I've reported related to KDialog:
Against KDE KDialog:
https:/
Status: "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://
Against KDialog it-self:
https:/
Status: this is only a small issue of bigger thing
Other bugs which I've reported related to KDE plasma-desktop:
Steps to Reproduce:
1. Click on KDE "start" button
2. Nothing happens.
3. After 1 minute and 30 seconds you'll see the context menu!
Some people say, it's better later, than never.
Against KDE plasma-desktop:
https:/
Status: currently ignored
And finally against the DBus it-self:
https:/
Status:
"This is probably the problem: there seems to be some sort of incompatibility
involving Ubuntu's "dbusmenu" system and how it interacts with Qt/KDE
applications. Please report this to the suppliers of the packages you're using
(Ubuntu, Kubuntu, or any third-party dbusmenu or KDE packages you're using).
I don't think this is a D-Bus bug."
Other related links:
http://<email address hidden>
As well currently I can't do any launchpad upgrade or send any apport-collect, because of these annoying bugs:
https:/
https:/
https:/
So to not repeating my-self and pasting a bunch of strace, debug stuff (which you can access from the links above), the current status of this big Ubuntu and KDE bug as suggested from DBus support, is as follow:
> (process:7387): GLib-GIO-WARNING **: Received property menu with type s does not match expected type o in the expected interface void DBusMenuImporte
Please report this to the suppliers of the packages you're using
(Ubuntu, Kubuntu, or any third-party dbusmenu or KDE packages you're using).
So now I'm reporting it now against Ubuntu, as my reports against KDE, X, DBus failed.
Related branches
In KDE Bug Tracking System #307049, Christoph-maxiom (christoph-maxiom) wrote : | #19 |
Please temporarily rename ~/.kde/
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #20 |
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.
In KDE Bug Tracking System #307049, Christoph-maxiom (christoph-maxiom) wrote : | #21 |
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?
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #22 |
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/
kdialog(
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=
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
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #23 |
strace gives me this:
8549 sendmsg(7, {msg_name(0)=NULL, msg_iov(
8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 1 ([{fd=7, revents=POLLIN}]) <0.000061>
8549 recvmsg(7, {msg_name(0)=NULL, msg_iov(
8549 recvmsg(7, 0x7fff71c561e0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) <0.000010>
8549 sendmsg(7, {msg_name(0)=NULL, msg_iov(
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.
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #24 |
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.
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #25 |
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(
8758 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.013023>
In KDE Bug Tracking System #307049, Christoph-maxiom (christoph-maxiom) wrote : | #26 |
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://
Probable candidates are network manager related modules, or anything that is related to package updates.
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #27 |
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?
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #28 |
Thanks for your help, I'll try to find some workaround for it.
In freedesktop.org Bugzilla #55136, kenorb (kenorb) wrote : | #7 |
Basically I've huge problems with dbus.
My main problem is that different binaries like kdialog and plasma-desktop are freezing and crashing all the time, so I can't use my Linux (Ubuntu) desktop properly.
Problems include:
https:/
https:/
Here is strace example of sent message by kdialog:
8549 sendmsg(7, {msg_name(0)=NULL, msg_iov(
8549 poll([{fd=7, events=POLLIN}], 1, 25000) = 1 ([{fd=7, revents=POLLIN}]) <0.000061>
8549 recvmsg(7, {msg_name(0)=NULL, msg_iov(
8549 recvmsg(7, 0x7fff71c561e0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) <0.000010>
8549 sendmsg(7, {msg_name(0)=NULL, msg_iov(
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 to run single popup window (kdialog).
The same happening with plasma-desktop, once I click on panel, it takes few minutes to react on my click!
Here are some socket statistics:
$ netstat -na | grep dbus | grep CONNECTED | wc -l
124
Is there any connection limit to dbus before the timeout?
$ 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
I was playing with dbus-monitor, but it didn't help anything, because it doesn't show even which process (PID) is connecting to it. I found some references to (--print-pid), but I didn't know how to use this feature.
Here is something, that I found as possible cause of it.
When starting dbus-daemon manually, I've the following error:
$ /bin/dbus-daemon --print-pid 5 --print-address 7 --session
Failed to start message bus: Writing to pipe: Bad file descriptor
Running with sudo doesn't help either.
strace gives me this:
stat("/
stat("/
open("/
fstat(5, {st_mode=
read(5, ""..., 68) = 68
close(5) = 0
stat("/
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #29 |
Related dbus bug:
https:/
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #30 |
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(
When I'm monitoring my dbus socket, it showed as:
$ dbus-monitor --address unix:path=
signal sender=
string ":1.71"
string ""
string ":1.71"
signal sender=
string ":1.71"
string ":1.71"
string ""
Destination is NULL.
This is other example how it suppose to look:
signal sender=
string ":1.66"
Maybe that's the reason of timeout?
In freedesktop.org Bugzilla #55136, kenorb (kenorb) wrote : | #8 |
[pid 15820] sendmsg(7, {msg_name(0)=NULL, msg_iov(
When I'm monitoring my dbus socket, it showed as:
$ dbus-monitor --address unix:path=
signal sender=
string ":1.71"
string ""
string ":1.71"
signal sender=
string ":1.71"
string ":1.71"
string ""
Destination is NULL, it's normal?
In freedesktop.org Bugzilla #55136, Simon McVittie (smcv) wrote : | #9 |
(In reply to comment #0)
> Basically I've huge problems with dbus.
> My main problem is that different binaries like kdialog and plasma-desktop are
> freezing and crashing all the time, so I can't use my Linux (Ubuntu) desktop
> properly.
Please report this to your distribution (Ubuntu).
> When starting dbus-daemon manually, I've the following error:
>
> $ /bin/dbus-daemon --print-pid 5 --print-address 7 --session
> Failed to start message bus: Writing to pipe: Bad file descriptor
File descriptors 5 and 7 are not open, so that error message is to be expected.
Running the session dbus-daemon is part of X session startup; you can't (usefully) attach a new dbus-daemon to a running session.
> Running with sudo doesn't help either.
No, it won't.
(In reply to comment #0)
> 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>
The default timeout for a D-Bus method call is 25 seconds, so this means your process (kdialog?) is sending a method call and not receiving a reply from the service it's communicating with. After 25 seconds, it gives up.
In freedesktop.org Bugzilla #55136, Simon McVittie (smcv) wrote : | #10 |
(In reply to comment #0)
> Is there any connection limit to dbus
It's limited by the number of file descriptors it's allowed to open, usually 1024. A few file descriptors are used internally, so you can have about 1000 connections.
In 1.4.x, Bug #23194 you'll run into problems at half of that limit, so about 500.
In freedesktop.org Bugzilla #55136, Simon McVittie (smcv) wrote : | #11 |
(In reply to comment #1)
> When I'm monitoring my dbus socket, it showed as:
> $ dbus-monitor --address unix:path=
When you are the only user logged in, there should usually be two dbus-daemon processes. One is the system bus (runs as user messagebus, listens on /var/run/
> Destination is NULL, it's normal?
Yes, broadcast signals have a null destination.
In freedesktop.org Bugzilla #55136, Simon McVittie (smcv) wrote : | #12 |
From one of the KDE bugs you linked:
> (process:7387): GLib-GIO-WARNING **: Received property menu with type s does not match expected type o in the expected interface void DBusMenuImporte
This is probably the problem: there seems to be some sort of incompatibility involving Ubuntu's "dbusmenu" system and how it interacts with Qt/KDE applications. Please report this to the suppliers of the packages you're using (Ubuntu, Kubuntu, or any third-party dbusmenu or KDE packages you're using).
I don't think this is a D-Bus bug.
In KDE Bug Tracking System #307049, Christoph-maxiom (christoph-maxiom) wrote : | #31 |
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.
In KDE Bug Tracking System #307049, Christoph-maxiom (christoph-maxiom) wrote : | #32 |
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?
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #33 |
I'm using full KDE plasma desktop.
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #34 |
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.
In freedesktop.org Bugzilla #55136, kenorb (kenorb) wrote : | #13 |
Thanks for the detailed explanation and help.
I've reported another bug report here as follow-up:
https:/
In freedesktop.org Bugzilla #55136, kenorb (kenorb) wrote : | #14 |
Sorry, wrong link.
This is the correct:
https:/
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #35 |
Current follow-up:
https:/
In KDE Bug Tracking System #307049, Christoph-maxiom (christoph-maxiom) wrote : | #36 |
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.
In freedesktop.org Bugzilla #55136, kenorb (kenorb) wrote : | #15 |
> When you are the only user logged in, there should usually be two dbus-daemon
> processes. One is the system bus (runs as user messagebus, listens on
> /var/run/
> own user ID, listens on some address involving /tmp which you can get from the
> $DBUS_SESSION_
> the results aren't likely to be very useful.
Also if I could use a little of your specific knowledge about dbus to know more about my specific problem with dbus involved and what are the methods of debugging the source of this problem.
My other dbus instance is here:
$ echo $DBUS_SESSION_
unix:abstract=
Also I can see it in netstat:
$ netstat -nap --unix | grep LISTEN | grep dbus | head -n1
unix 2 [ ACC ] STREAM LISTENING 13380 1970/dbus-daemon @/tmp/dbus-
But the problem is, that /tmp/dbus-
$ ll /tmp/dbus-
ls: cannot access /tmp/dbus-
$ netstat -nap --unix | grep 4Lf6aHxvqg | wc -l
71
items are connected to this bus socket which doesn't exist.
This could be also the reason of that problem?
Also when debugging dbus-daemon, it gives me this:
recvmsg(17, {msg_name(0)=NULL, msg_iov(
recvmsg(17, 0x7fffde52f3e0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLOUT}], 1, 0) = 0 (Timeout)
..
recvmsg(59, {msg_name(0)=NULL, msg_iov(
recvmsg(59, 0x7fffde52f3e0, MSG_CMSG_CLOEXEC) = -...
In freedesktop.org Bugzilla #55136, Simon McVittie (smcv) wrote : | #16 |
(In reply to comment #8)
> My other dbus instance is here:
> $ echo $DBUS_SESSION_
> unix:abstract=
>
> Also I can see it in netstat:
> $ netstat -nap --unix | grep LISTEN | grep dbus | head -n1
> unix 2 [ ACC ] STREAM LISTENING 13380 1970/dbus-daemon
> @/tmp/dbus-
>
> But the problem is, that /tmp/dbus-
It's an "abstract Unix socket" which doesn't exist in the filesystem, which means that when dbus-daemon exits, it doesn't need to delete a Unix socket special file like it would when using normal Unix sockets. Its address is actually "\0/tmp/
This is normal, on OSs that have abstract Unix sockets (Linux and possibly Solaris, but not *BSD).
> recvmsg(59, 0x7fffde52f3e0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily
> unavailable)
It is normal for an idle dbus-daemon to encounter EAGAIN. That just means "there are no more messages for you to read right now, try again later".
> Or maybe there is some better and cleaner way of diagnosing the problem.
dbus-monitor(1) and d-feet (a GUI application) might be helpful.
> Also how do I use --print-pid option in practical way to print actual PID of
> processes which are connecting to dbus?
That's not what that option does. It's nothing to do with the process IDs of D-Bus clients:
> kenorb 1970 0.0 0.1 30000 5856 ? Ss Sep19 0:07
> //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
Early in its startup, that process will have printed its own pid (1970 in this case) to file descriptor 5, and its address to file descriptor 7. Those file descriptors were pipes to dbus-launch, which was its parent process: it's how dbus-launch finds out what values to put in your GUI session's $DBUS_SESSION_
kenorb (kenorb) wrote : | #1 |
I've installed d-feet and it gives me some interesting results, like (each of them repeating plenty of times):
$ d-fee
ERROR: Some clever service is trying to be cute and has the same signal name in the same interface
ERROR: Some clever service is trying to be cute and has the same method name in the same interface
ERROR:dbus.
org.freedesktop
ERROR:dbus.
ERROR:dbus.
ERROR:dbus.
ERROR:dbus.
ERROR:dbus.
ERROR:dbus.
ERROR:dbus.
org.freedesktop...
tags: | added: dbus |
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #37 |
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/
$ sudo rename 's/.desktop/
$ kbuildsycoca4
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #38 |
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.
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #39 |
E.g.:
Enabling all modules starting with letter 'k':
$ sudo rename 's/.disabled//' k*.desktop.disabled
$ killall -HUP kdeinit4
kenorb (kenorb) wrote : | #2 |
I can confirm, that this is caused by muon-notifier service.
After renaming /usr/share/
$ dpkg -l | grep muon-notifier
ii muon-notifier 1.3.1-0ubuntu2 update notifier for KDE
affects: | kde-baseapps (Ubuntu) → muon (Ubuntu) |
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #40 |
It looks line muon-notifier is the one which breaks kdialog functionality and plasma-desktop panel.
File: muon-notifier.
Whatever it's.
Renaming /usr/share/
and restarting kdeinit4 solve the problem.
$ dpkg -l | grep muon-notifier
ii muon-notifier 1.3.1-0ubuntu2 update notifier for KDE
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #41 |
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.
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.
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #42 |
Enabling muon-notifier.
kenorb 11328 0.0 0.3 131788 12392 ? S 13:55 0:00 /usr/bin/python /usr/share/
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/
Unhandled exception in thread started by <bound method MetaReleaseCore
Traceback (most recent call last):
File "/usr/lib/
uri=
File "/usr/lib/
return _opener.open(url, data, timeout)
File "/usr/lib/
response = self._open(req, data)
File "/usr/lib/
'_open', req)
File "/usr/lib/
result = func(*args)
...
File "/usr/lib/
data = self._sock.
socket.error: [Errno 104] Connection reset by peer
Probably, because I'm behind the proxy.
kenorb (kenorb) wrote : | #3 |
Killing the following process solve the problem:
kenorb 11328 0.0 0.3 131788 12392 ? S 13:55 0:00 /usr/bin/python /usr/share/
In freedesktop.org Bugzilla #55136, kenorb (kenorb) wrote : | #17 |
Thanks for the help.
I found the broken kde module: muon-notifier
After killing this process, my desktop started to breath.
kenorb (kenorb) wrote : | #4 |
When running it manually again using the same command line, I've this error:
/usr/bin/python /usr/share/
Unhandled exception in thread started by <bound method MetaReleaseCore
Traceback (most recent call last):
File "/usr/lib/
uri=
File "/usr/lib/
return _opener.open(url, data, timeout)
File "/usr/lib/
response = self._open(req, data)
File "/usr/lib/
'_open', req)
File "/usr/lib/
result = func(*args)
...
File "/usr/lib/
data = self._sock.
socket.error: [Errno 104] Connection reset by peer
Probably, because I'm behind the proxy.
In KDE Bug Tracking System #307049, Jonathan Thomas (echidnaman) wrote : | #43 |
Git commit c67667633ada69b
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/distupgrad
http://
In KDE Bug Tracking System #307049, Jonathan Thomas (echidnaman) wrote : | #44 |
Git commit ae8bcd2062e0285
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/distupgrad
http://
In KDE Bug Tracking System #307049, Jonathan Thomas (echidnaman) wrote : | #45 |
Git commit abeacf1a952813f
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/distupgrad
http://
no longer affects: | dbus (Ubuntu) |
no longer affects: | kde-baseapps (Ubuntu) |
Jonathan Thomas (echidnaman) wrote : | #5 |
I've committed a fix upstream for 1.4.1: http://
Changed in muon (Ubuntu): | |
status: | New → Fix Committed |
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #46 |
I've updated this script, but it seems it still failing when running it:
$ python -d /usr/share/
Unhandled exception in thread started by <bound method MetaReleaseCore
Traceback (most recent call last):
File "/usr/lib/
uri=
File "/usr/lib/
return _opener.open(url, data, timeout)
File "/usr/lib/
response = self._open(req, data)
File "/usr/lib/
'_open', req)
File "/usr/lib/
result = func(*args)
File "/usr/lib/
return self.do_
File "/usr/lib/
r = h.getresponse(
File "/usr/lib/
response.
File "/usr/lib/
version, status, reason = self._read_status()
File "/usr/lib/
line = self.fp.readline()
File "/usr/lib/
data = self._sock.
socket.error: [Errno 104] Connection reset by peer
Even there is try/except
In KDE Bug Tracking System #307049, Jonathan Thomas (echidnaman) wrote : | #47 |
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)
In KDE Bug Tracking System #307049, kenorb (kenorb) wrote : | #48 |
I've tried, but it doesn't change anything.
Maybe because it's a separate thread?
Problem is happening in File "/usr/lib/
So the exception was caught by /usr/lib/
socket.error: [Errno 104] Connection reset by peer
python -m trace -c -t /usr/share/
MetaRelease.
MetaRelease.
--- modulename: genericpath, funcname: getsize
genericpath.py(49): return os.stat(
MetaRelease.
MetaRelease.
releasechecker(35): while metaRelease.
releasechecker(36): time.sleep(1)
Unhandled exception in thread started by <bound method MetaReleaseCore
Traceback (most recent call last):
File "/usr/lib/
uri=
File "/usr/lib/
return _opener.open(url, data, timeout)
File "/usr/lib/
response = self._open(req, data)
File "/usr/lib/
'_open', req)
File "/usr/lib/
result = func(*args)
File "/usr/lib/
return self.do_
File "/usr/lib/
r = h.getresponse(
File "/usr/lib/
response.
File "/usr/lib/
version, status, reason = self._read_status()
File "/usr/lib/
line = self.fp.readline()
File "/usr/lib/
data = self._sock.
socket.error: [Errno 104] Connection reset by peer
releasechecker(35): while metaRelease.
releasechecker(36): time.sleep(1)
releasechecker(35): while metaRelease.
releasechecker(36): time.sleep(1)
releasechecker(35): while metaRelease.
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://
In KDE Bug Tracking System #307049, Jonathan Thomas (echidnaman) wrote : | #49 |
Git commit 6d9581b2984c89e
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/distupgrad
http://
In KDE Bug Tracking System #307049, Jonathan Thomas (echidnaman) wrote : | #50 |
Git commit f4821f9050ccd4e
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/distupgrad
http://
In KDE Bug Tracking System #307049, Jonathan Thomas (echidnaman) wrote : | #51 |
Git commit 4028651c70dc854
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/distupgrad
http://
In KDE Bug Tracking System #307049, Jonathan Thomas (echidnaman) wrote : | #52 |
(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.
In KDE Bug Tracking System #307049, Jonathan Thomas (echidnaman) wrote : | #53 |
Git commit 058d412f365744c
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/MuonNotifi
M +5 -2 kded/MuonNotifier.h
M +0 -24 kded/distupgrad
M +0 -3 kded/distupgrad
M +1 -0 kded/distupgrad
http://
In KDE Bug Tracking System #307049, Jonathan Thomas (echidnaman) wrote : | #54 |
Git commit 90bd4c2d893c76b
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/MuonNotifi
M +5 -2 kded/MuonNotifier.h
M +0 -24 kded/distupgrad
M +0 -3 kded/distupgrad
M +1 -0 kded/distupgrad
http://
In KDE Bug Tracking System #307049, Jonathan Thomas (echidnaman) wrote : | #55 |
Git commit 5029d1618767118
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/MuonNotifi
M +5 -2 kded/MuonNotifier.h
M +0 -24 kded/distupgrad
M +0 -3 kded/distupgrad
M +1 -0 kded/distupgrad
http://
Launchpad Janitor (janitor) wrote : | #6 |
This bug was fixed in the package muon - 1.4.1-0ubuntu1
---------------
muon (1.4.1-0ubuntu1) quantal; urgency=low
* New upstream bugfix release (LP: #1053910)
-- Jonathan Thomas <email address hidden> Sat, 29 Sep 2012 15:08:07 -0400
Changed in muon (Ubuntu): | |
status: | Fix Committed → Fix Released |
Changed in dbus: | |
importance: | Unknown → High |
status: | Unknown → Won't Fix |
Changed in muon: | |
importance: | Unknown → High |
status: | Unknown → Fix Released |
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: /code.google. com/p/chromium/ issues/ entry
1. Go to: https:/
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: Sites/x/ sites/all/ modules/ contrib/ simpletest_ clone
strace kdialog --attach=71303405 --title=Open File --getopenfilename /home/kenorb/
It seems to stop on poll for exactly 25 seconds!
write(3, "\1\0\0\0\0\0\0\0", 8) = 8 POLLIN| POLLOUT} ], 1, -1) = 1 ([{fd=6, revents=POLLOUT}]) 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 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 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 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=6, events=
writev(6, [{"\225\
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(
poll([{fd=7, events=POLLIN}], 1, 25000) = 1 ([{fd=7, revents=POLLIN}])
recvmsg(7, {msg_name(0)=NULL, msg_iov(
recvmsg(7, 0x7fff4ef79770, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
sendmsg(7, {msg_name(0)=NULL, msg_iov(
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