FS#34128 - [chromium] dolphin extremely slow startup and slow behaviour
Attached to Project:
Arch Linux
Opened by Bogomil (smirky) - Sunday, 03 March 2013, 11:17 GMT
Last edited by Evangelos Foutras (foutrelis) - Monday, 08 April 2013, 13:51 GMT
Opened by Bogomil (smirky) - Sunday, 03 March 2013, 11:17 GMT
Last edited by Evangelos Foutras (foutrelis) - Monday, 08 April 2013, 13:51 GMT
|
Details
Description:
The Dolphin file manager in KDE starts up very slowly and after ~30 seconds it starts, but everything I do with it, takes about another 30 seconds to be done. Until then the applications is completely freezed up and most of the times, KDE prompts a force close solution. This doesn't happen all the time, but when it happesn, only a reboot "fixes" it temporary and after a while it gets bugged again. Additional info: * package version(s) - kdebase-dolphin 4.10.0-1 * config and/or log files etc. Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated. "/org/freedesktop/UDisks2/drives/Hitachi_HDS721050CLA362_JP1540HN2D653H" : property "Drive" does not exist "/org/freedesktop/UDisks2/drives/Hitachi_HDS721616PLA380_PVG904Z5T0PN2V" : property "Drive" does not exist "/org/freedesktop/UDisks2/drives/Optiarc_DVD_RW_AD_7240S" : property "Drive" does not exist "/org/freedesktop/UDisks2/drives/SAMSUNG_File_Stor_Gadget_0019322f7c059e_1" : property "Drive" does not exist "/org/freedesktop/UDisks2/drives/SAMSUNG_File_Stor_Gadget_0019322f7c059e" : property "Drive" does not exist "/org/freedesktop/UDisks2/drives/Hitachi_HDS721616PLA380_PVG904Z5T0PN2V" : property "DeviceNumber" does not exist "/org/freedesktop/UDisks2/drives/Hitachi_HDS721616PLA380_PVG904Z5T0PN2V" : property "Device" does not exist This is dump is from launching dolphin through a terminal. I googled a few reports about this issue, but the answers were pointing to distro handling. Steps to reproduce: Run Dolphin on KDE 4.10 |
This task depends upon
Closed by Evangelos Foutras (foutrelis)
Monday, 08 April 2013, 13:51 GMT
Reason for closing: Fixed
Additional comments about closing: Ideally we would want to re-enable tcmalloc once it's fixed upstream (either Chromium or NVIDIA).
Monday, 08 April 2013, 13:51 GMT
Reason for closing: Fixed
Additional comments about closing: Ideally we would want to re-enable tcmalloc once it's fixed upstream (either Chromium or NVIDIA).
Recently I've experienced Chromium problems, leaving zombies and in a thread I've read that these zombies can cause KDE apps to lag as I described above. Killing those processes is the solution for me so far.
About the Chromium bug:
I traced the problem a little bit deeper and
https://bbs.archlinux.org/viewtopic.php?pid=1241006
https://code.google.com/p/chromium/issues/detail?id=123583
there were a few more, but I think those are enough to make a point. The problem seems to NOT be in Chromium but in the NVIDIA drivers with some kind of a talloc or something. This was discussed in a few reports in the Chrome/Chromium bug tracking list and those were the comments. So what's left I think is NVIDIA to clean their mess. I have a hunch they already did, because new drivers are already released, but they are not in the arch packages yet. I really hope this gets fixed upstream. I think this bug report can be closed, since it's not in the hands of the arch devs :)