Summary: | Crash - QProcess::waitForFinished - Running out of file descriptors | ||
---|---|---|---|
Product: | [Unmaintained] nepomuk | Reporter: | Alban Pearce <alban> |
Component: | fileindexer | Assignee: | Nepomuk Bugs Coordination <nepomuk-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | andy.boettger, axel.krebs, bart.deruyter, besenic.d, bladud, bradaffleck, bugzilla, cfeck, ch, cyberang3l, dns_hmpf, dobson187, fbrunnerreg, honkir, jbowler, johannes.schwall, kenny1, loic.grobol, m.wege, martin.runge, master.homer, me, mzanetti, oleg.atamanenko+kde, rdieter, rollin_brant, ronbu3, s5saso, sven.burmeister, thebigming, thothonegan |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/nepomuk-core/630939e388beb4eaf6387a4f9bb827a87fdd0478 | Version Fixed In: | 4.10.1 |
Sentry Crash Report: | |||
Attachments: |
New crash information added by DrKonqi
New crash information added by DrKonqi New crash information added by DrKonqi New crash information added by DrKonqi New crash information added by DrKonqi |
Description
Alban Pearce
2012-11-27 18:57:05 UTC
Could you please post what *exactly* you were doing with kmail? Were you checking for mail? Was it indexing new mail? Does it crash on startup? Similar reports suggest this can be caused by running out of file descriptors. What happens when you run kbuildsycoca4 from the command line? Does it also crash? Could you (after the crash has occurred) verify this by finding the pid of the nepomukfileindexer process (look in top output for something called "nepomukservicestub nepomukfileindexer"). Once you have it, could you post the result of ls /proc/$pid/fd ? Could you also post the result of ulimit -a? Thanks Created attachment 76094 [details]
New crash information added by DrKonqi
nepomukservicestub (0.1.0) on KDE Platform 4.9.95 using Qt 4.8.3
- What I was doing when the application crashed: right after logging in from the screen locker, DrKonqi started and signaled this crash. I have activated indexation for a new folder earlier today.
-- Backtrace (Reduced):
#6 0x00007fa4db564425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#7 0x00007fa4db567b8b in __GI_abort () at abort.c:91
[...]
#9 0x00007fa4db63882c in __GI___fortify_fail (msg=<optimized out>) at fortify_fail.c:38
#10 0x00007fa4db637700 in __GI___chk_fail () at chk_fail.c:29
#11 0x00007fa4db6387be in __fdelt_chk (d=<optimized out>) at fdelt_chk.c:26
*** Bug 312548 has been marked as a duplicate of this bug. *** *** Bug 312547 has been marked as a duplicate of this bug. *** *** Bug 312925 has been marked as a duplicate of this bug. *** Created attachment 76418 [details]
New crash information added by DrKonqi
nepomukservicestub (0.1.0) on KDE Platform 4.9.97 using Qt 4.8.3
- Unusual behavior I noticed:
Nepomuk crashed without any reason.
-- Backtrace (Reduced):
#11 0x00007f1035b92854 in QProcessPrivate::waitForStarted (this=0x44d0ff0, msecs=30000) at io/qprocess_unix.cpp:1038
#12 0x00007f1035b4cf53 in QProcess::waitForFinished (this=0x2318f50, msecs=30000) at io/qprocess.cpp:1752
#13 0x00007f10249fa856 in Nepomuk2::FileIndexingJob::slotProcessTimerTimeout (this=0x2352d20) at ../../../services/fileindexer/fileindexingjob.cpp:118
[...]
#15 0x00007f1035bcc26c in QObject::event (this=0x3bfe690, e=<optimized out>) at kernel/qobject.cpp:1157
#16 0x00007f1033ee1e9c in QApplicationPrivate::notify_helper (this=this@entry=0x1f5a4d0, receiver=receiver@entry=0x3bfe690, e=e@entry=0x7fff592d2220) at kernel/qapplication.cpp:4562
Nepomukservicestub crashes when Chakra Linux is loaded and in other instances if using KDE 4.9.97. Created attachment 76528 [details]
New crash information added by DrKonqi
nepomukservicestub (0.1.0) on KDE Platform 4.9.97 using Qt 4.8.3
- What I was doing when the application crashed: Nepomukservicestub crashed with no obvious reason or user interaction.
-- Backtrace (Reduced):
#6 0x00007f98ed53b425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#7 0x00007f98ed53eb8b in __GI_abort () at abort.c:91
[...]
#9 0x00007f98ed60f82c in __GI___fortify_fail (msg=<optimized out>) at fortify_fail.c:38
#10 0x00007f98ed60e700 in __GI___chk_fail () at chk_fail.c:29
#11 0x00007f98ed60f7be in __fdelt_chk (d=<optimized out>) at fdelt_chk.c:26
*** Bug 313664 has been marked as a duplicate of this bug. *** *** Bug 313552 has been marked as a duplicate of this bug. *** *** Bug 313713 has been marked as a duplicate of this bug. *** Hey guys. Could you please provide the following information (preferably just after the crash)- $ lsof | wc -l $ sysctl fs.file-nr The first command should give us the number of open files, and the second command will give us 3 numbers - <allocated file handles, unused but allocated file handles, maximum number of file handler>. Created attachment 76760 [details]
New crash information added by DrKonqi
nepomukservicestub (0.1.0) on KDE Platform 4.9.98 using Qt 4.8.4
- What I was doing when the application crashed:
Nepomuk crashed hile indexing new files in the background.
-- Backtrace (Reduced):
#12 0x00007fe6bd187f64 in QProcessPrivate::waitForStarted (this=0x34adc50, msecs=30000) at io/qprocess_unix.cpp:1030
#13 0x00007fe6bd142983 in QProcess::waitForFinished (this=0x33659c0, msecs=30000) at io/qprocess.cpp:1752
#14 0x00007fe6ae203036 in Nepomuk2::FileIndexingJob::slotProcessTimerTimeout (this=0x3472180) at /usr/src/debug/nepomuk-core-4.9.98/services/fileindexer/fileindexingjob.cpp:118
[...]
#16 0x00007fe6bd1c140c in QObject::event (this=0x30330b0, e=<optimized out>) at kernel/qobject.cpp:1165
#17 0x00007fe6bb29585c in QApplicationPrivate::notify_helper (this=this@entry=0xce7750, receiver=receiver@entry=0x30330b0, e=e@entry=0x7fffee7b92b0) at kernel/qapplication.cpp:4562
Does Nepomuk use a QFileSystemWatcher per directory? As far as I see, each instance allocates an FD. (In reply to comment #14) > Does Nepomuk use a QFileSystemWatcher per directory? As far as I see, each > instance allocates an FD. Nope. We do allocate one inotify watch per directory, but that is NOT a file descriptor, and we have been doing that since 4.4 or 4.3 *** Bug 314432 has been marked as a duplicate of this bug. *** Bug 314432 indicates that the indexer might try to start non-existant executables using QProcess, which due to a Qt bug, fails to cleanup pipes. *** Bug 313721 has been marked as a duplicate of this bug. *** Well, QProcess creates a pipe so you can get a signal when the process exists. The problem here is that there are no checks in QProcess for this (except for the warning), and there is no way to check for that in the code. Look at this mailing list for more information: http://www.mail-archive.com/nepomuk@kde.org/msg03539.html *** Bug 314257 has been marked as a duplicate of this bug. *** *** Bug 314965 has been marked as a duplicate of this bug. *** *** Bug 314986 has been marked as a duplicate of this bug. *** It would be awesome if someone could test the patch over here - https://git.reviewboard.kde.org/r/108950/ @Vishesh Handa I can confirm that the patch works, and that the crash was in fact due to it opening a descriptor for every directory (which in turn opened a pipe). Git commit 630939e388beb4eaf6387a4f9bb827a87fdd0478 by Vishesh Handa. Committed on 14/02/2013 at 08:40. Pushed by vhanda into branch 'KDE/4.10'. FileIndexer: Do not use QDirIterators in the queues A DirIterator works by opening the directory (as a file) and reading its contents, which are the list of files in that directory. As long as the dirIterator is open, it consumes one file descriptor. When iterating over all the folders, by using QDirIterator, we open a new file descriptor per directory. Since we traverse the file system via breadth first, the number of valid QDirIterators can get quite high. This sometimes results in us exceeding the number of file descriptors required which results in a crash, cause QProcess doesn't handle running out of file descriptors. Instead we now just iterate over all the directories and store them as strings. This may consume more memory, but it is better than a crash. REVIEW: 108950 M +6 -33 services/fileindexer/basicindexingqueue.cpp M +0 -1 services/fileindexer/basicindexingqueue.h http://commits.kde.org/nepomuk-core/630939e388beb4eaf6387a4f9bb827a87fdd0478 Good job, merci! *** Bug 315184 has been marked as a duplicate of this bug. *** *** Bug 315236 has been marked as a duplicate of this bug. *** *** Bug 315257 has been marked as a duplicate of this bug. *** *** Bug 315342 has been marked as a duplicate of this bug. *** *** Bug 315458 has been marked as a duplicate of this bug. *** *** Bug 315532 has been marked as a duplicate of this bug. *** *** Bug 315589 has been marked as a duplicate of this bug. *** *** Bug 315634 has been marked as a duplicate of this bug. *** *** Bug 315733 has been marked as a duplicate of this bug. *** *** Bug 315823 has been marked as a duplicate of this bug. *** *** Bug 316052 has been marked as a duplicate of this bug. *** Created attachment 77754 [details]
New crash information added by DrKonqi
nepomukservicestub (0.1.0) on KDE Platform 4.10.00 using Qt 4.8.3
- What I was doing when the application crashed:
Nothing, system was left alone idle
- Custom settings of the application:
Specified a proxy server in the office today, nepomuk crashed two times at home where this proxy is not in reach. I did not observe crashes before I set the proxy.
-- Backtrace (Reduced):
#5 0x00007f3ad2022425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#6 0x00007f3ad2025b8b in __GI_abort () at abort.c:91
[...]
#8 0x00007f3ad20f682c in __GI___fortify_fail (msg=<optimized out>) at fortify_fail.c:38
#9 0x00007f3ad20f5700 in __GI___chk_fail () at chk_fail.c:29
#10 0x00007f3ad20f67be in __fdelt_chk (d=<optimized out>) at fdelt_chk.c:26
I don't know whether this is a KDE or SuSE problem. The substance of this e-mail is being sent to both. ## Output from Yast Online Update A package dependency could not be found. More information is available in the detailed report: # Detailed Report patch:openSUSE-2013-456-1.noarch conflicts with libqt4-debuginfo.x86_64 < 4.8.4-3.6.1 provided by libqt4-debuginfo-4.8.4-3.3.1.x86_64 ## Output from Yast Online Update when the patch is excluded This update is important as it may solve critical problems. This update fixes the following issues with libqt4: - Add check-return-value-of-qt_safe_pipe.patch: * fixes QTBUG#18934 and kde#310777 For more information about bugs fixed by this update please visit this website: • https://bugs.kde.org/show_bug.cgi?id=310777 Repository: repo-update #### YaST2 conflicts list - generated 2013-06-27 15:26:42 #### patch:openSUSE-2013-456-1.noarch conflicts with libqt4-debuginfo.x86_64 < 4.8.4-3.6.1 provided by libqt4-debuginfo-4.8.4-3.3.1.x86_64 [ ] deinstallation of libqt4-debuginfo-4.8.4-3.3.1.x86_64 [ ] do not install patch:openSUSE-2013-456-1.noarch #### YaST2 conflicts list END ### ############################################ System: Host: linux-mn4n.site Kernel: 3.7.10-1.16-desktop x86_64 (64 bit, gcc: 4.7.2) Desktop KDE 4.10.3 (Qt 4.8.4) Distro: openSUSE 12.3 (x86_64) VERSION = 12.3 CODENAME = Dartmouth Machine: System: SAMSUNG (portable) product: RV411/RV511/E3511/S3511/RV711 Mobo: SAMSUNG model: RV411/RV511/E3511/S3511/RV711 Bios: Phoenix version: 03PA.M001.20110312.XW date: 03/12/2011 CPU: Dual core Intel Core i5 CPU M 480 (-HT-MCP-) cache: 3072 KB flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 10640.2 Clock Speeds: 1: 2667.00 MHz 2: 1199.00 MHz 3: 1199.00 MHz 4: 1199.00 MHz Duncan, please don't add unrelated reports to bugs, but file a new one instead. |