Bug 142457 - temp files not cleaned up after crashes
Summary: temp files not cleaned up after crashes
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: ImageEditor-Undo (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: HI crash
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-03 14:52 UTC by Heiner Lamprecht
Modified: 2020-08-13 15:52 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 0.9.5


Attachments
should fix the removing of cache files on normal close (428 bytes, patch)
2008-07-09 11:49 UTC, Andi Clemens
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Heiner Lamprecht 2007-03-03 14:52:09 UTC
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.
Comment 1 caulier.gilles 2007-04-10 16:06:06 UTC
*** Bug 144033 has been marked as a duplicate of this bug. ***
Comment 2 Arnd Baecker 2007-07-01 11:59:43 UTC
Where do the temporary files end up (hopefully in /tmp)?
Comment 3 Sputnik 2007-07-01 12:16:48 UTC
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!
Comment 4 Arnd Baecker 2007-07-01 14:29:00 UTC
OK, increased priority. 
(Still, neither digikam nor showfoto should crash in the very first place ;-)
Comment 5 Achim Bohnet 2007-07-02 00:32:19 UTC
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).
Comment 6 J Appel 2008-01-10 18:16:11 UTC
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.
Comment 7 Arnd Baecker 2008-01-10 19:04:04 UTC
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
Comment 8 Arnd Baecker 2008-04-28 06:27:38 UTC
Sounds related to: http://bugs.kde.org/show_bug.cgi?id=161347
("kipi-plugins doesn't clean properly ~/tmp/kde-username")
Comment 9 Sputnik 2008-04-28 08:38:02 UTC
@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!!!
Comment 10 caulier.gilles 2008-04-28 08:44:56 UTC
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
Comment 11 Sputnik 2008-04-28 08:52:29 UTC
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...
Comment 12 caulier.gilles 2008-04-28 09:02:01 UTC
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
Comment 13 Arnd Baecker 2008-04-28 09:27:44 UTC
> ------- 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
Comment 14 Sputnik 2008-04-28 12:03:56 UTC
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!
Comment 15 Arnd Baecker 2008-04-28 17:41:14 UTC
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).
Comment 16 Sputnik 2008-06-29 09:15:31 UTC
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 ()
Comment 17 caulier.gilles 2008-06-29 10:10:54 UTC
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
Comment 18 Sputnik 2008-06-29 11:15:27 UTC
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! :)
Comment 19 Andi Clemens 2008-07-09 10:52:43 UTC
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.
Comment 20 Andi Clemens 2008-07-09 11:05:08 UTC
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...
Comment 21 caulier.gilles 2008-07-09 11:11:52 UTC
Andi,

If i remmember, we use KTempFile for that. there is a method named setAutoDelete(). Perhaps the problem is here.

Gilles Caulier
Comment 22 Sputnik 2008-07-09 11:19:33 UTC
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!!!! :)

Comment 23 Andi Clemens 2008-07-09 11:49:53 UTC
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.
Comment 24 caulier.gilles 2008-07-09 12:01:30 UTC
Andi,

Patch fine for me.

Gilles
Comment 25 caulier.gilles 2008-07-09 12:11:16 UTC
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

Comment 26 caulier.gilles 2008-07-09 12:17:29 UTC
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
Comment 27 Andi Clemens 2008-07-09 12:28:12 UTC
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
Comment 28 Andi Clemens 2008-07-09 12:31:55 UTC
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?
Comment 29 caulier.gilles 2008-07-09 12:40:25 UTC
Andi,

No sure... but i remember a similar problem with KDialog...

So, if you cannot confirm this, that fine for me.

Gilles
Comment 30 Andi Clemens 2008-07-22 02:50:02 UTC
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?
Comment 31 Sputnik 2008-07-22 03:45:05 UTC
Fixing ShowFoto might be a good step forward! - Thanks for your work and effort, Andi!
Comment 32 caulier.gilles 2008-07-22 09:46:32 UTC
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
Comment 33 Andi Clemens 2008-10-21 21:22:55 UTC
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