Version: (using KDE KDE 3.5.6) Installed from: SuSE RPMs Compiler: gcc version 4.0.2 OS: Linux If the digikam or showfoto crashes in ImageEditor, temporary files are not cleaned up and will remain on the disc. Instead, the application should clean the directory on startup.
*** Bug 144033 has been marked as a duplicate of this bug. ***
Where do the temporary files end up (hopefully in /tmp)?
No, it is "/var/tmp/kdecache-USERNAME/showFoto/" for ShowFoto - and "/var/tmp/kdecache-USERNAME/digikam/" for digikam. (See here: http://bugs.kde.org/show_bug.cgi?id=144033 ) I personally have no problems with digikam! The digikam tmp-folder is clean! But I have to tidy up the showFoto-folder regulary. Or else my system crashes. I have already lost data several times. It is highly suggested to give this bug a higher priority!
OK, increased priority. (Still, neither digikam nor showfoto should crash in the very first place ;-)
mhmm, maybe: opening the tempfile, then immediatly remove the file would do autocleanup in case of a crash (when the file is closed by the system).
I encounter the same (just run out of disk space btw). Wouldnt on startup a if _this is the only instance of showfoto running_ do rm *.* in /var/tmp/kdecache-USERNAME/digikam/ solve the situation until a better fix is available? confirming the bug as i can reproduce with showfoto 0.9.2.
Somehow I have the strong feeling that we should try to get rid of the crashes in the first place. Then the problem discussed here would not arise ;-) (However, crash-freeness of digikam/showfoto cannot be guaruanteed, even if we could blame all crashes to external applications...). Still: please report the crashes as separate bugs, together with a suitable backtrace so that such problems can be fixed! Thanks a lot in advance, Arnd
Sounds related to: http://bugs.kde.org/show_bug.cgi?id=161347 ("kipi-plugins doesn't clean properly ~/tmp/kde-username")
@Arnd Baecker I did not answer this for a long time - but in that time I hade dozends of critical crashes that took down the whole linux system due to diskplace problems. - Including lost data etc. This is the ONLY high bug that I have with Linux. And I do have it since more than A YEAR now! - Excuse me for using capitals, but this is the most annoying bug that I know in the whole open source community. - And it takes data with it. I once lost the work of several hours because of no diskspace left. There is no other software in the moment that I know of on my system that has similar negative aspects. This has always been caused by showfoto - and Linux always could be made startable after just cleaning up the /var/tmp/kdecache-<username>/showFoto directory. And I higly would recommend to always clean up properly this directory by hand after having just used showFoto - or to risk the chance of loosing valuable data that may have nothing to do with images. The whole KDE can not run - and also can not go down properly with not enough diskspace to save the running session. I would not recommend to wait with this problem after having fixed everything else!! btw. I normally have about one gigabyte free on my root partition. showFoto needs indeed mostly several sessions to fill the diskspace up to the rim, but it could be filled up with perhaps 5 different photos. I use a 7 Megapixel camera. - I do like to use showFoto for several included features and its RAW-capabilities. Please write me if I can help with any informations! Go on with writing good software with nice things! - But just fix this as fast as possible: Please!!!
Sputnik, The temp url are allocated by KDE API. I don't know why KDE do not have a way to cleanup automatically all temp url between KDE sessions (at least). Gilles Caulier
Thanks for letting me know, Gilles! I do not have problems with digikam though... Everything is cleaned up properly in the /var/tmp/kdecache-<username>/digiKam/ folder...
You want mean than only showfoto have this problem with temp file created. I'm so surprized because showfoto and digiKam image editor use the same implementation... Perhaps also, digiKam do not crash like showfoto on your computer... Gilles Caulier
> ------- Additional Comments From sputnikshock gmail com 2008-04-28 08:38 ------- > Arnd Baecker I did not answer this for a long time - but in that time I > hade dozends of critical crashes that took down the whole linux system > due to diskplace problems. - Including lost data etc. Sputnik: Note that the original report talks about temporary files being left-over after crashes of showfoto or the image editor. If this also applies to your situation, can you please point me at the corresponding bug reports, discussing the crashes themselves? Or if you experience a different situation, please explain in detail. > This is the ONLY high bug that I have with Linux. And I do have it > since more than A YEAR now! - Excuse me for using capitals, but this is > the most annoying bug that I know in the whole open source community. - > And it takes data with it. I once lost the work of several hours because > of no diskspace left. There is no other software in the moment that I > know of on my system that has similar negative aspects. The good thing about open source is that the source in open, i.e. you can download it and improve it by providing patches. All the development is done in the people's free time, so more contributors are always welcome! Arnd
Thanks Gilles, thanks, Arnd! It seems that my showFoto also doesn't clean up when not crashing. Second: After starting the program to get the information about my version to post here, showFoto just crashed without having done any other operation. Here are my current version informations: KDE Version 0.7.0 (KDE 3.5.9, Kubuntu (gutsy) 4:3.5.9-0ubuntu1~gutsy1~ppa1) Operating System Linux (i686) release 2.6.22-14-generic Compiler Target: i486-linux-gnu This is the last crash result from the 'empty' showFoto: --- (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) [...] (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1237170496 (LWP 19328)] [New Thread -1243419760 (LWP 19330)] (no debugging symbols found) [...] (no debugging symbols found) [KCrash handler] #6 0xb69c00c0 in ?? () from /lib/tls/i686/cmov/libc.so.6 #7 0xbfc701bc in ?? () #8 0xb7f637c4 in ?? () #9 0x00000000 in ?? () --- Thanks again!
Sputnik: the problem with your crash report is "(no debugging symbols found)". A proper backtrace which includes debugging symbols is needed to find the source of the problem. This means that you will have to recompile digikam, libkexiv, exiv2, ... and so with debugging enabled. See http://www.digikam.org/?q=contrib under "If you are experiencing crashes with digiKam" and for installation instructions "http://www.digikam.org/?q=download/svn" under "Install digiKam in your Home Directory". Alternatively you may try the dbg packages for digikam 0.9.3 from http://www.mpe.mpg.de/~ach/kubuntu/gutsy/ Please file a separate bug for each crash with 0.9.3 (unless that crash is already listed in the bug tracker).
Ok. I did not understand the easy way of just installing the dbg-packages - so the bug report needed some time. This crash here comes the most often when ShowFoto is started standalone as an imageviewer from outside digikam. There is a very high chance that this crash occurs. The program shows a crash-note after closing. The most urgent thing for the user is again not that the application crashed on exit but that the temp-files keep staying in the /var/tmp/kdecache... directory. They will never be cleaned away and (as stated above) and can bring down linux itself on a system with low space in that directory. This is the backtrace that I could get: [Thread debugging using libthread_db enabled] [New Thread 0xb643a8d0 (LWP 25784)] [New Thread 0xb5ec6b90 (LWP 25788)] [KCrash handler] #6 0xb69e5e10 in ?? () from /lib/tls/i686/cmov/libc.so.6 #7 0xb69e788e in ?? () from /lib/tls/i686/cmov/libc.so.6 #8 0xb69eb4f0 in free () from /lib/tls/i686/cmov/libc.so.6 #9 0xb6ba7b11 in operator delete () from /usr/lib/libstdc++.so.6 #10 0xb6ba7b6d in operator delete[] () from /usr/lib/libstdc++.so.6 #11 0xb729cd30 in ~QStringData (this=0x825a7c8) at tools/qstring.h:366 #12 0xb72943af in QStringData::deleteSelf (this=0x825a7c8) at tools/qstring.cpp:1561 #13 0x08094dc5 in QMapPrivate<QString, QString>::clear (this=0x825b928, p=0x846bc3f) at /usr/share/qt3/include/qstring.h:851 #14 0x08094da6 in QMapPrivate<QString, QString>::clear (this=0x825b928, p=0x8256b48) at /usr/share/qt3/include/qmap.h:491 #15 0x08094e2c in QMapPrivate<QString, QString>::clear (this=0x825b928) at /usr/share/qt3/include/qmap.h:480 #16 0xb6f6e451 in ~QMapPrivate (this=0x825b928) at tools/qmap.h:374 #17 0xb72a41f2 in ~QMap (this=0x82630d8) at tools/qmap.h:647 #18 0xb72a4221 in ~QSettingsGroup (this=0x82630d8) at ../include/private/qsettings_p.h:67 #19 0xb72a4256 in ~QMapNode (this=0x82630c8) at tools/qmap.h:87 #20 0xb72a42a4 in QMapPrivate<QString, QSettingsGroup>::clear ( this=0x825f9c8, p=0x82630c8) at tools/qmap.h:493 #21 0xb72a4285 in QMapPrivate<QString, QSettingsGroup>::clear ( this=0x825f9c8, p=0x8269200) at tools/qmap.h:491 #22 0xb72a42ec in QMapPrivate<QString, QSettingsGroup>::clear (this=0x825f9c8) at tools/qmap.h:480 #23 0xb72a434d in ~QMapPrivate (this=0x825f9c8) at tools/qmap.h:374 #24 0xb72a4b08 in ~QMap (this=0x8256d58) at tools/qmap.h:647 #25 0xb72a4b37 in ~QSettingsHeading (this=0x8256d58) at ../include/private/qsettings_p.h:76 #26 0xb72a4b6c in ~QMapNode (this=0x8256d48) at tools/qmap.h:87 #27 0xb72a4bba in QMapPrivate<QString, QSettingsHeading>::clear ( this=0x825b560, p=0x8256d48) at tools/qmap.h:493 #28 0xb72a4c02 in QMapPrivate<QString, QSettingsHeading>::clear ( this=0x825b560) at tools/qmap.h:480 #29 0xb72a4c63 in ~QMapPrivate (this=0x825b560) at tools/qmap.h:374 #30 0xb72a4cca in ~QMap (this=0x826b2c4) at tools/qmap.h:647 #31 0xb729dae4 in ~QSettingsPrivate (this=0x826b2c0) at tools/qsettings.cpp:525 #32 0xb72a0152 in ~QSettings (this=0x825e3b8) at tools/qsettings.cpp:930 #33 0xb725ddea in ~QSingleCleanupHandler (this=0xb745e080) at ../include/qcleanuphandler.h:96 #34 0xb725c2be in __tcf_0 () at tools/qcomlibrary.cpp:382 #35 0xb69aa3b1 in __cxa_finalize () from /lib/tls/i686/cmov/libc.so.6 #36 0xb6e8a3a3 in __do_global_dtors_aux () from /usr/lib/libqt-mt.so.3 #37 0xb73543ec in _fini () from /usr/lib/libqt-mt.so.3 #38 0xb7f33fdf in ?? () from /lib/ld-linux.so.2 #39 0xb69aa084 in exit () from /lib/tls/i686/cmov/libc.so.6 #40 0xb6992458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #41 0x0807a9c1 in _start ()
Sputnik, Sound like a crash which have been fixed in 0.9.4.rc1. Please try to reproduce it with this version. Thanks in advance Gilles Caulier
Thanks, Gilles! Great news! I am not sure if I can satisfy your request in the moment - but will however pay attention to this bug when it occurs and report it here! Thanks again! :)
I tested this and it is true: showFoto doesn't clean up the cache, even if it was closed properly, but digiKam does. If I kill digiKam while using image editor, it also doesn't clean the cache folder (sure, it has no time to do that). But as mentioned before in this bugreport, showFoto really leaves the temp files in the kdecache folder!! Simple test: 1. open showFoto 2. edit image 3. close showFoto without saving the image 4. look in temp folder Tested it four times now, this is definitely true. We really need to make sure on startup if files are in the temp folder and clean it up manually... this should not be a big problem. Maybe this is fixed for KDE4 already, but KDE3 doesn't clean it up at all.
Another comment: I have a separate var partition, because pacman (the package manager from archlinux) works better with JFS / XFS or ReiserFS, normally I use ext3. So I made a separate file-system for that. After playing around with showFoto to test this case, the cache folder for showFoto contained 756 MB cache files!! Ok I'm working with high resolution images, but nevertheless if my partition would be full (and it nearly was), I might have lost my package managers database (happened once before, kdevelop flooded my temp folder that day). So I really think this issue is important and should be fixed. I'll have a look at it...
Andi, If i remmember, we use KTempFile for that. there is a method named setAutoDelete(). Perhaps the problem is here. Gilles Caulier
Just a 'thanks' to you, Andi! - This is excatly what happened to me. And as I had a smaller root partition on my laptop this regulary brought the system down. - Ofcourse the - system itself - (with no space available to save anything) what also had the sideefect of not being able to start X or the KDE-desktop anymore before cleaning up the cache... Old bug though... Thanks for regarding it!!!! :)
Created attachment 25979 [details] should fix the removing of cache files on normal close somehow the closeEvent from imageeditor window is not processed by showfoto, I put the essential code from closeEvent into the queryClose method of showfoto... works fine. Sure this doesn't solve the cleaning of the temp folder on startup, but it does at least operate the normal way like digikam imageeditor.
Andi, Patch fine for me. Gilles
Andi, About the not cleaned tmp path when crash appear, i think there is a solution... Look into undocache.cpp code. When the instance of this class is created by UndoManager, this last one created by DImgInterface, a new cache tmp folder is created on the system (typically into /var/...) The global idea is to register somewhere this path when new UndoManager instance is created. If crash appears, at the next session, we just need to check the last cache tmp folder and if it exist, just to remove it... But take a care: this can be more complex than a simple string to record in digikamrc file (for ex., my first idea here), because, for showfoto or digiKam, more than one instance can be started at the same time... We need to record too the process id somewhere, or something like that... Gilles
With KDE4, it can be better to use KTemporaryFile class into UndoCache. look here : http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKTemporaryFile.html Gilles Caulier
SVN commit 829870 by aclemens: cache files were not removed when closing showFoto because the closeEvent from ImageEditorWindow was not processed at all. This was fixed by putting all essential content of closeEvent() into the queryClose() method of showFoto. M +4 -0 showfoto.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=829870
Gilles, in KDE4 showFoto is clearing up the cache folder on close. Although the queryClose() method is not changed at all... seems to be a KDE3 / Qt3 specific problem?
Andi, No sure... but i remember a similar problem with KDialog... So, if you cannot confirm this, that fine for me. Gilles
I think it is nearly impossible to solve the cleanup of left over cache files, because you can always have multiple instances of showFoto / digiKam running. This makes it very hard to decide which files can be removed and which not. If you want to be platform independent (every system has its own way of defining / getting process IDs), this can't be done... or I'm just not able to find a good solution. I spent a lot of time on this now and somehow I'm tired of it. All in all this is KDE's fault, not digiKam, because the cache dirs are not cleanup on logout. This seems to be fixed in KDE4, so I will stop working on this for KDE3 branch. One of the problems was that showFoto didn't cleanup cache files at all, even not on a clean shutdown of the program. This was fixed in the current SVN (and 0.9.4 final). But deleting old cache files (at least on logout) should be done by KDE itself... So I'm thinking about closing this one now... Is this ok for you all?
Fixing ShowFoto might be a good step forward! - Thanks for your work and effort, Andi!
Andi, If you think than someting must be done in KDELibs, move thi sfile to the right bugzilla components of kdelibs section and wait and see comments from developpers. Note: unforget to set the right email to re-route meesages at te right place. Gilles
Gilles, I guess I will close this one now, since the main problem has been solved, the rest is related to KDE and seems to be fixed in KDE4 as well. If we need it we can re-open it anyway. Andi