Version: (using KDE 4.0.98) Installed from: SuSE RPMs Compiler: gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] OS: Linux Well, the title says it all. Every time I hover over a PDF file a zombie process is left, closing dolphin kills all the zombies.
On Wed, Jul 16, 2008 at 03:39:19PM -0000, auxsvr@yahoo.com wrote: Hej, > Well, the title says it all. Every time I hover over a PDF file a zombie process > is left, closing dolphin kills all the zombies. I guess Strigi::ProcessInputStream should call wait(pid) in its dtor to avoid zombie processes. Ciao, Tobias
Version: trunk Compiler: g++ (Debian 4.3.1-2) 4.3.1 Revision: kdebase: r840373 kdelibs: 840049 same problem with nepomukstrigiservice: ... 24411 ? ZN 0:00 [pdftotext] <defunct> 24412 ? ZN 0:00 [pdftotext] <defunct> 24413 ? ZN 0:00 [pdftotext] <defunct> 24414 ? ZN 0:00 [pdftotext] <defunct> 24415 ? ZN 0:00 [pdftotext] <defunct> 24416 ? ZN 0:00 [pdftotext] <defunct> 24417 ? ZN 0:00 [pdftotext] <defunct> 24418 ? ZN 0:00 [pdftotext] <defunct> ... I have over 50 zombies process after 1 day
I can confirm this but it is not clear what is really causing it. But i see them all with dolphin as their parent.
I got the same problem here, but with strigidaemon as the parent. It looks like this: 2423 ? Sl 0:08 /usr/bin/nepomukserver 2425 ? Sl 197:01 \_ /usr/bin/nepomukservicestub nepomukstorage 2435 ? S 4:24 \_ /usr/bin/nepomukservicestub nepomukfilewatch 2436 ? S 4:10 \_ /usr/bin/nepomukservicestub nepomukontologyloader 2563 ? Sl 0:00 \_ /usr/bin/nepomukservicestub nepomukstrigiservice 2565 ? Sl 14:53 \_ /usr/bin/strigidaemon 2576 ? ZN 0:02 \_ [pdftotext] <defunct> 2577 ? ZN 0:02 \_ [pdftotext] <defunct> 2578 ? ZN 0:06 \_ [pdftotext] <defunct> 2579 ? ZN 0:07 \_ [pdftotext] <defunct> and so on... Happening during initial indexing, going on for 200 cpu minutes now. I'm not sure, whether it's gonna finish at all, but I'll leave it running overnight to give it a sporting chance. KDE 4.1.2 on Gentoo ~x86. I'm not sure if that is the bug's fault, but dolphin is right now next to unusable. It was running well before but since all those processes appeared it came to the proverbial grinding halt. I can't gdb attach or strace to the processes so I can't give any more information but feel free to ask if I once again forgot to provide the obvious. Many thanks and greetings... Stephan
I have a very similar problem but the zombie processes are listed with dolphin as parent: |-dolphin---3*[pdftotext] |-nepomukserver-+-3*[nepomukservices] | |-nepomukservices-+-strigidaemon---5*[{strigidaemon}] | | `-{nepomukservices} | `-{nepomukserver} Using dolphin Version: 4:4.1.2-0ubuntu4 As soon as these defunct processes appear, dolphin also stops showing nepomuk tags and comments.
Additional: Problem persists when neither strigi daemon nor nepomuk server are running, though seemingly slightly harder to replicate - needs a fair amount of hovering to get one defunct pdftotext pdftotext is provided by xpdf, in this case Version: 3.02-1.4ubuntu1 which is the most recent version afaik.
The same problem still exists on KDE 4.1.4 on Gentoo
similar situation here. evey time i hover on a big pdf file, dolphin process eats 99% cpu usage but no pdftotext processes are spawned. I am running kde-4.2.0 on gentoo
Same problem here. Tried to rename some pdf-files, it was a mess. Dolphin becomes really slow and sometimes froze.
Same problem here in archlinux. KDE 4.2.1, dolphin 1.2.1, CPU Intel(R) Pentium(R) M processor 1.50GHz (dothan). The problem is very annoying! For me the severity should be critical. It means KDE is not usable anymore and one needs to think of alternatives to dolphin... Here is a detailed description of the problem. When navigating with dolphin in a directory where there is at least a pdf file. When the mouse cursor is left on top of the pdf file in the detailed view mode, the CPU is reaching 99% when getting pdf information, freezing dolphin. The pdf file is about 7.2 M big. The 99% CPU is due to a pdftotext process: /usr/bin/pdftot/usr/bin/pdftotext -enc UTF-8 /tmp/strigiArJI0T - In fact the problem seems very simple, dolphin (or strigi?) simply run pdftotext on the entire pdf file! If I run pdftotext manually, it takes about 10 seconds of 99% CPU to convert pdf to text which is approximatly the same interval of time as the dolphin freeze... The solution would be to analize only the first page which is much much faster: With the full PDF of size 7,2M, pdftotext takes exactly 17s here. With only the first page it takes 0.053s (which would result in a unvisible freezing of dolphin) Here is what I did to improve speed. I used pdftk to do that. THe name of the pdf file is 1.pdf: pdftk 1.pdf cat 1 output out.pdf time pdftotext out.pdf real 0m0.053s user 0m0.023s sys 0m0.007s ANd if I run pdftotext on the original big file: time pdftotext 1.pdf real 0m16.099s user 0m13.976s sys 0m0.520s
Well, I understand strigi has to read the whole file in order to index it, doesn't it? However, you are right, severity could be improved. Anyone? S.
Well, here I think is not running so that every time that I pass through the icon of a big pdf file, it freezes dolphin. By the way I don't know how to activate strigi?. I guess that if strigi is running it just do indexation of the file if it is modified?
OK, I think my problem is different, please forget my 2 last messages. I think it's a distinct bug.
KDE Version 1.2.1 (KDE 4.2.4 (KDE 4.2.4), Arch Linux) Operating System Linux (x86_64) release 2.6.30-ARCH Same problem here, dolphin freezes for a few seconds and system monitor shows pdftotext hoggin cpu in the meantime. However I don't see any zombie process. Stringi is not enabled on my desktop so that may be why no zombie is left.
Debian bug #539488
I freeze during preview: pstree look like: |-dolphin-+-bash | |-pdftotext | `-{dolphin}
Ok this bug is different than mine. This bug lie in libstream. Please see strigi/src/streamanalyzer/endanalyzers/helperendanalyzer.cpp:82: string exepath = findPath("pdftotext", paths);
The problem lie in the information pannel, when the information pannel is disable navigation is smooth.
Ok therefore my analysis: - dolphin/src/infosidebarpage.cpp is not fully async refreching this sidebar should not block the event loop - this pannel should use a thread a lower priority than the main windows, information are not really a priority task instead of browsing - the point about indexing a whole document is valid
this bug was clonned for the dolphin part as https://bugs.kde.org/show_bug.cgi?id=202234 The pdftotext call should be now moved to strigi, this bug is not in kdelibs Bastien
Any news of this bug
I don't see this happen anymore. (KDE 4.4.5)
Could you close this bug. Could not reproduce anymore
Same here, closing as fixed.