Bug 252855

Summary: Palapeli filled up /tmp area on disk
Product: [Applications] palapeli Reporter: Ian Wadham <iandw.au>
Component: generalAssignee: Stefan Majewsky <majewsky>
Status: RESOLVED FIXED    
Severity: normal CC: kde-games-bugs-null
Priority: NOR    
Version First Reported In: 1.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Ian Wadham 2010-09-30 13:26:29 UTC
Version:           1.0 (KDE SC 4.4) (using Devel) 
OS:                Linux

Palapeli creates a succession of sub-directories named palapeli<random_6_bytes> in the /tmp/ianw-kde4.6/kde-ianw directory (the login name being "ianw"), but it does not seem to purge them.  They can fill up the root or /tmp partition, with some unpleasant consequences.

I currently have 514 such sub-directories.  They range in time from 30 June 2010 to 29 Sept 2010 in my case and have a total size of 4.05 Gb.  They range in size from 1.6 Mb to 16.7 Mb.  I have been playing a lot with puzzles of 1000 pieces and 4000 pieces lately.  The sub-directory files seem to contain saved pieces and states from previous sessions of Palapeli.

Reproducible: Didn't try

Steps to Reproduce:
Play Palapeli hundreds of times with puzzle sizes >=1000 pieces. Recently I have been playing a lot with 4000 pieces, previously with 1000 and 250 pieces.

Actual Results:  
/tmp grows without limit.  If you have /tmp on the root partition (the distro default), the entire system can get creeping paralysis as the root partition fills up, e.g. unable to download from web pages, unable to update software from distro, unable to load a Palapeli puzzle and play again.

Expected Results:  
Palapeli should keep a limited backlog of /tmp files per puzzle attempted: ideally just one file per currently unsolved puzzle.

OS: Linux (i686) release 2.6.31.12-0.2-desktop
Compiler: gccpalapeli1thfqH
Comment 1 Stefan Majewsky 2011-04-03 14:47:43 UTC
After the recent refactoring, the relevant instances are now cleaned up properly, as in: I can't reproduce this on trunk. I'm not marking this as fixed yet because I need to include something in main() that cleans up the existing mess.
Comment 2 Justin Zobel 2021-03-09 23:51:10 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.
Comment 3 Ian Wadham 2021-03-10 00:18:43 UTC
Was fixed by the original author, but bug status was not updated back then.