| Summary: | konqueror file manager crash on tab refresh | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | Wayne E. Nail <waynenail> |
| Component: | general | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | adawit, adunstan, waltsaw, waynenail, zxq9 |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 4.7 | |
| Sentry Crash Report: | |||
| Attachments: |
New crash information added by DrKonqi
New crash information added by DrKonqi New crash information added by DrKonqi |
||
|
Description
Wayne E. Nail
2011-10-23 22:44:23 UTC
Created attachment 64899 [details]
New crash information added by DrKonqi
konqueror (4.6.5 (4.6.5)) on KDE Platform 4.6.5 (4.6.5) using Qt 4.7.4
- What I was doing when the application crashed:
This crash persists and has no special relationship with refreshing tabs, and is multiply repeatable. Normally I have three konqueror filemanager instances open on my desktop in the same workspace, two as my user, and one as root (kdesu, and please don't start with how this is a bad idea because I've yet to screw anything up in years and years of using it this way).
If I leave any of these instances open but 'untended' for some period of time yet to be discovered -- more than a few minutes but less than five hours -- once I refocus upon any of those instances and attempt to perform any action, the instance simply vanishes. Poof. Gone.
This bug may be related to 284841 ... and it may be that the plasma crash is the defining time factor that will cause konqueror instances to vanish on next visit. That is, after the plasma crash and automatic plasma reload, the next time I visit one of the konqueror instances, that instance will disappear. However, it may be the case that the plasma crash does not need to happen first for the konqueror instance to disappear.
Both the plasma crash (284841) bug and this konqueror bug began after the same yum update on 22 October 2011.
- Unusual behavior I noticed:
Each konqueror instance remains on the desktop unless and until I transfer focus to it (I use 'focus follows mouse'). Once focused, I must then perform some action -- click on a tab, folder, filename, etc -- to cause that instance to disappear.
Sometimes, but not always, one of the three konqueror instances disappearing will take another instance with it. The odd part about this is that at least once, the root instance of konqueror took one of the user instances of konqueror with it, leaving the remaining user instance of konqueror onscreen. However, once that remaining instance of konqueror is focused upon and an action is performed in that window, that instance also disappears.
-- Backtrace (Reduced):
#10 0x009ae487 in g_logv (log_domain=0xa0eca6 "GLib", log_level=<value optimized out>, format=0xa148c4 "Cannot create pipe main loop wake-up: %s\n", args1=0xb53d617c "\364+\222") at gmessages.c:557
#11 0x009ae4c3 in g_log (log_domain=0xa0eca6 "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xa148c4 "Cannot create pipe main loop wake-up: %s\n") at gmessages.c:577
#12 0x009a1dbc in g_main_context_init_pipe (context=0xb4a004e8) at gmain.c:520
#13 0x009a21c5 in g_main_context_new () at gmain.c:615
#14 0x07b369b6 in QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate (this=0xb4a00478, context=0x0) at kernel/qeventdispatcher_glib.cpp:310
Created attachment 65026 [details]
New crash information added by DrKonqi
konqueror (4.6.5 (4.6.5)) on KDE Platform 4.6.5 (4.6.5) using Qt 4.7.4
- What I was doing when the application crashed:
The konqueror file management instance (one of three loaded; this one and another as user, a third one as root) crashed while not focused upon or being used in any active way, as I have described in earlier reports. The active app at the time of this crash happened to be Showimg, but these crashes seem to happen no matter what app I am presently using.
The other two konqueror file management instances are still onscreen, but will disappear if I try to do anything with them, and if I invoke Settings/Configure Konqueror I will get an error:
'Cannot load library /usr/lib/kde4/kcm_konqhtml.so: (usr/lib/kde4/kcm_konqhtml.so: cannot open shared object file. Too many open files)'
Actual number of open files: (user) $ lsof -u username | wc -l
17033
Actual number of open files: (root) # lsof -u root | wc -l
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/username/.gvfs
Output information may be incomplete.
4056
I am more sure than ever that this bug and 284841 are related/intertwined.
Both these bugs continue to happen every 3.5 hours and it is extremely frustrating, in that it acts more like a WinOS registry corruption than any linux problem I have ever encountered.
If there is a way to reinstall kde then I am happy to try that. The system as is can barely be described as usable.
-- Backtrace (Reduced):
#10 0x009ae487 in g_logv (log_domain=0xa0eca6 "GLib", log_level=<value optimized out>, format=0xa148c4 "Cannot create pipe main loop wake-up: %s\n", args1=0xb38ff17c "\364+\222") at gmessages.c:557
#11 0x009ae4c3 in g_log (log_domain=0xa0eca6 "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xa148c4 "Cannot create pipe main loop wake-up: %s\n") at gmessages.c:577
#12 0x009a1dbc in g_main_context_init_pipe (context=0xb3a4ea30) at gmain.c:520
#13 0x009a21c5 in g_main_context_new () at gmain.c:615
#14 0x07b369b6 in QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate (this=0xb3a623f8, context=0x0) at kernel/qeventdispatcher_glib.cpp:310
Created attachment 65201 [details]
New crash information added by DrKonqi
konqueror (4.6.5 (4.6.5)) on KDE Platform 4.6.5 (4.6.5) using Qt 4.7.4
- What I was doing when the application crashed:
Switched focus to konqueror filemanager instance and as soon as I clicked a file (once, to select, not activate) konqueror vanished.
Above reports/comments are mine as well, and this is the same problem.
I had hoped today's 2.6.35.14-103.fc14.i686.PAE kernel update fixed the problem, but it has not.
In the event an
-- Backtrace (Reduced):
#10 0x009ae487 in g_logv (log_domain=0xa0eca6 "GLib", log_level=<value optimized out>, format=0xa148c4 "Cannot create pipe main loop wake-up: %s\n", args1=0xb488e17c "\364+\222") at gmessages.c:557
#11 0x009ae4c3 in g_log (log_domain=0xa0eca6 "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xa148c4 "Cannot create pipe main loop wake-up: %s\n") at gmessages.c:577
#12 0x009a1dbc in g_main_context_init_pipe (context=0xb3f18d60) at gmain.c:520
#13 0x009a21c5 in g_main_context_new () at gmain.c:615
#14 0x07b369b6 in QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate (this=0xb3f02cd0, context=0x0) at kernel/qeventdispatcher_glib.cpp:310
(In reply to comment #3) > Created an attachment (id=65201) [details] > New crash information added by DrKonqi > > konqueror (4.6.5 (4.6.5)) on KDE Platform 4.6.5 (4.6.5) using Qt 4.7.4 > > - What I was doing when the application crashed: > > Switched focus to konqueror filemanager instance and as soon as I clicked a > file (once, to select, not activate) konqueror vanished. > > Above reports/comments are mine as well, and this is the same problem. > > I had hoped today's 2.6.35.14-103.fc14.i686.PAE kernel update fixed the > problem, but it has not. > > In the event an > > -- Backtrace (Reduced): > #10 0x009ae487 in g_logv (log_domain=0xa0eca6 "GLib", log_level=<value > optimized out>, format=0xa148c4 "Cannot create pipe main loop wake-up: %s\n", > args1=0xb488e17c "\364+\222") at gmessages.c:557 > #11 0x009ae4c3 in g_log (log_domain=0xa0eca6 "GLib", > log_level=G_LOG_LEVEL_ERROR, format=0xa148c4 "Cannot create pipe main loop > wake-up: %s\n") at gmessages.c:577 > #12 0x009a1dbc in g_main_context_init_pipe (context=0xb3f18d60) at gmain.c:520 > #13 0x009a21c5 in g_main_context_new () at gmain.c:615 > #14 0x07b369b6 in QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate > (this=0xb3f02cd0, context=0x0) at kernel/qeventdispatcher_glib.cpp:310 According to https://bugreports.qt.nokia.com//browse/QTBUG-12211, this type of error is caused by leaking file descriptors and such a leak was fixed in KIO for KDE 4.7.1. See the first two commits at https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/changes/kio/kio/slavebase.cpp. Any chance you are able to update to KDE >= 4.7.1 and see if the problem persists for you ? Thank you Dawit Alemayehu. I read the links you provided, but I have a poor frame of reference to understand them very well. The Fedora 14 updates-testing repos I use carry these versions: kdebase.i686 6:4.6.5-2.fc14 @updates-testing kdebase-devel.i686 6:4.6.5-2.fc14 @updates-testing kdebase-libs.i686 6:4.6.5-2.fc14 @updates-testing Unfortunately, I believe I lack the requisite skills and depth of knowledge to go 'out-of-repo' for KDE 4.7.1, as this is my primary working system and I depend upon it. I barely understand what 'leaking file descriptors' means. If I knew how to reinstall kde-everything to this system -- *without losing my configurations* -- I would do so. My primary concerns are to identify whether this is a known regression *introduced* by new code, or some corruption of my own installation (there are no hardware faults or fsck problems). This problem *behaves* in bizarre fashion not unlike WinOS registry corruption, a first for me since Red Hat 8.0 in 2003. I can put up with this problem if I have some idea that it is known and will be fixed. The workaround meanwhile is to close any instances of konqueror which have not (yet) crashed and then reload all three I normally run, and to deal with the (related, I am more certain than ever) plasma-desktop crash by letting it reload after crashing, or catch the CPU pegging before the crash and kill/restart plasma-desktop manually. Other running apps do not appear to be affected. My inexpert observation leads me to believe that bug 284841 is related to this bug. (In reply to comment #5) > Thank you Dawit Alemayehu. > > I read the links you provided, but I have a poor frame of reference to > understand them very well. > > The Fedora 14 updates-testing repos I use carry these versions: > kdebase.i686 6:4.6.5-2.fc14 @updates-testing > kdebase-devel.i686 6:4.6.5-2.fc14 @updates-testing > kdebase-libs.i686 6:4.6.5-2.fc14 @updates-testing Not knowing all the details about the Fedora distribution, I will simply venture to guess that Fedora 14 is far too old to come with the most upto date version of KDE SC ?? That probably means that you have to upgrade your distribution to Fedora 15 to get the latest KDE packages. > Unfortunately, I believe I lack the requisite skills and depth of knowledge to > go 'out-of-repo' for KDE 4.7.1, as this is my primary working system and I > depend upon it. I barely understand what 'leaking file descriptors' means. In case you are interested, leaking file descriptors means a file or a network socket was opened for reading or writting, but never closed when the read/write operation performed on it was completed. Simply put it is a programming error. You can find out more about "file descriptors" themselves at http://en.wikipedia.org/wiki/File_descriptor. > If I knew how to reinstall kde-everything to this system -- *without losing my > configurations* -- I would do so. I do not think re-installing will help you at all since the issue seems to be caused by a bug. See below. > My primary concerns are to identify whether this is a known regression > *introduced* by new code, or some corruption of my own installation (there are > no hardware faults or fsck problems). The problem with that is the cause of the file descriptor leak might not necessarily be a KDE process or application. It could be another system process and KDE just gets hit by it or it could be caused by KDE. Hence, if you upgrade and the problem is gone, we would know what the cause was. It was either the leak that I mentioned was fixed for 4.7.1 or another leak somewhere else that happen to have already been addressed in the latest versions. IOW, I cannot tell you what you want to know because I obviously have never encountered this problem on my system. > This problem *behaves* in bizarre fashion not unlike WinOS registry corruption, a first > for me since Red Hat 8.0 in 2003. Well, it is not really a corruption issue. What seems to be happening here is an application or a system process is simply using up all the file descriptors your system can allocate because it is not releasing them after use. It is similar to a memory leak. Anyhow, you can check the maximum number of file descriptors your system can allocate by issuing "sysctl fs.file-nr" on the command line. For example, on my system I get the following: $ sysctl fs.file-nr fs.file-nr = 2880 0 305121 As you can see my system can accomodate over 305 thousand descriptors at a time and there are currently only 2880 in use. Once you find this out, then you have to go through a more involved process to determine which process is consuming all your file descriptors. That is why it is far easier to simply upgrade to the latest KDE version and see if your problem disappears. > I can put up with this problem if I have some idea that it is known and will be > fixed. > > The workaround meanwhile is to close any instances of konqueror which have not > (yet) crashed and then reload all three I normally run, and to deal with the > (related, I am more certain than ever) plasma-desktop crash by letting it > reload after crashing, or catch the CPU pegging before the crash and > kill/restart plasma-desktop manually. Other running apps do not appear to be > affected. > > My inexpert observation leads me to believe that bug 284841 is related to this > bug. Only applications that open a network request or a file after the system maximum is reached are affected and that usually means Konqueror and or Plasma applets. Dawit Alemayehu -- You cannot imagine how much I treasure your thoughtful and informative response! Think of a large number, double it, and that is how many hours of searching you have gifted me in a few sentences. Thanks to you I now have a decent understanding of what is wrong and what options I may pursue to correct it. Fedora 15 has been a little rocky on two other boxes here, and I hesitated to update my primary (Fedora 14) box for that reason. Fedora has been good about backporting fixes for deal-killer problems, but now I know I must plan an F15 upgrade, be happily surprised if a fix comes suddenly from the Fedora repos, or find a good howto for an in situ update to KDE 4.7.1. Thank you as well for explaining this is not a corruption issue or a failed install/update. My own file descriptor limit: $ sysctl fs.file-nr fs.file-nr = 20256 0 824566 In the unlikely event this is useful, here is the smolt url for this system: http://www.smolts.org/client/show_all/pub_3b16fb8c-1e5a-4284-9b5c-417e19327ecd Concerning what system process or application may be leaking, I wonder whether the java of a freenet node may be among the offenders. However, the konqueror crash and plasma-desktop crash clearly appeared together immediately after a yum update, whereas neither the java code nor the bittorrent client code (another user of many files) changed then or for weeks before or since. (In reply to comment #7) > Dawit Alemayehu -- > > You cannot imagine how much I treasure your thoughtful and informative > response! Think of a large number, double it, and that is how many hours of > searching you have gifted me in a few sentences. Thanks to you I now have a > decent understanding of what is wrong and what options I may pursue to correct > it. You are welcome. > Fedora 15 has been a little rocky on two other boxes here, and I hesitated to > update my primary (Fedora 14) box for that reason. Fedora has been good about > backporting fixes for deal-killer problems, but now I know I must plan an F15 > upgrade, be happily surprised if a fix comes suddenly from the Fedora repos, or > find a good howto for an in situ update to KDE 4.7.1. > > Thank you as well for explaining this is not a corruption issue or a failed > install/update. > > My own file descriptor limit: > $ sysctl fs.file-nr > fs.file-nr = 20256 0 824566 > > In the unlikely event this is useful, here is the smolt url for this system: > http://www.smolts.org/client/show_all/pub_3b16fb8c-1e5a-4284-9b5c-417e19327ecd > > Concerning what system process or application may be leaking, I wonder whether > the java of a freenet node may be among the offenders. However, the konqueror > crash and plasma-desktop crash clearly appeared together immediately after a > yum update, whereas neither the java code nor the bittorrent client code > (another user of many files) changed then or for weeks before or since. In that case, you are highly likely being hit with the leak that was fixed in 4.7.1 and your problem will probably be fixed by updating to that version. I dunno if can find KDE 4.7.x packages for your current version of the distro you are using, but that is something you can find out. Please update this ticket once you update to the latest stable KDE version. Thanks for the report. An attempt to upgrade Fedora 14 to KDE 4.7.x failed. An in situ upgrade from Fedora 14 to Fedora 15, using the 'preupgrade' ( https://fedoraproject.org/wiki/How_to_use_PreUpgrade ) was successful. The KDE version native to F15 is 4.6.x or so, and both the konqueror vanishing and plasma-desktop crashing ( bug 284841 ) still happened just as before. To upgrade to KDE 4.7.x, as root I added rdeiter's repo: cd /etc/yum.repos.d wget http://repos.fedorapeople.org/repos/rdieter/kde47/fedora-kde47.repo yum update This operation was successful. I was upgraded to KDE 4.7.2. Both the konqueror vanishing and plasma-desktop crashing problems went away. Today a yum update to KDE 4.7.3 from the fedora-kde47 repo was successful and the problems have not returned. Given that Fedora 14 is about one day away from EOL and thus unlikely to receive the KDE upgrade required to fix the problems, I recommend this bug be marked closed. I am posting the same recommendation for bug 284841. Again, I thank you for the information I needed to take an intelligent course of action to resolve these problems. I would not have been able to do it without your help. *** Bug 286570 has been marked as a duplicate of this bug. *** *** Bug 286792 has been marked as a duplicate of this bug. *** *** Bug 286974 has been marked as a duplicate of this bug. *** |