ImageMagick Bug Report: Imagemagick is eating up tmp-resources

ImageMagick Bug Report: Imagemagick is eating up tmp-resources

[benny]

[-- Attachment #1: Type: text/plain, Size: 16 bytes --]


see attachement

[-- Attachment #2: bug-report-imagemagick --]
[-- Type: application/octet-stream, Size: 3192 bytes --]


Dear all,

this problem exist under various versions of ImageMagick under various FS (FFS, ext2/3, reiser)
under various OSs (eg. Mandrake, Suse, FreeBSD).

When opening multipage-tiff-files made with Kodak Imaging (comes with WinX) with the command

display [path-to-tiff-file]

the process grows permanently, creates a bunch of temp-files and forces the system (sooner or later)
to run out of space. for a more detailed description please read the forwarded entry from
comp.unix.bsd.freebsd.misc.

If you need some example-tiff-files, please contact me directly (linuxATmarcrenearnsDOTde)

Since I am no recipient of your mailing list, please send any direct answers to me directly

Benny


Anfang der weitergeleiteten Nachricht:

Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Crashing a system by too much temporary file usage was Re: FreeBSD   is not the answer


On Thu, 15 May 2003 20:55:53 +0200
benny <linux@marcrenearns.de> wrote:

B> Am Thu, 15 May 2003 19:32:55 +0200
B> schrieb xxx:
B> 
B> > B> but for shure: first top says sometihng like
B> > B> "PRI SIZE      STATE     CPU
B> > B>  -14  511M   INODE    4%  "
B> > B> 
B> > B> for  display
B> > B> 
B> > B> after a while you got some 
B> > B> 
B> > B> "vnode_pager_putpages: I/O error 28"
B> > 
B> > 	That's not good - and not a symptom I associate with a simple disc
B> > full problem. Has /tmp run out of inodes (try df -i).

	This was educational - whatever ImageMagick is trying to do
with this tiff file it isn't good. What blew up the system was a
bunch of temporary files (names from tmpnam so no choice they're in
/var/tmp) opened but not closed and holding just under 90MB each. Given
time it pushes /var/tmp into overfull and gets the disc heads thrashing
(presumably trying to find a free block) - and it doesn't give up.
Sooner or later it is display that's stuck in a system call waiting
for a block (which it will never get) and then it is too late to kill it
and get it to free all that space up.

	I'm not sure why the filesystem layer isn't calling a halt on
the whole mess before it gets to the point of no return, if any VM
gurus are listening they may be able to shed some light. It seems
that it is a common problem (I'll try it on a Slowaris box next
week if that's OK with you Benny).

	At this point it seems that it is also impossible to get at /var
and delete something (probably locked waiting for that block hunt to
finish). Unmounting /var is also impossible (even forced) for similar
reasons AFAICT.

	The good news is that if /var/tmp has about 1.5GB free then
display finally reaches the point (at 2.5GB in size and 1.5GB of temp
files) of discovering there isn't enough memory for the X11 window
and dies - without bothering the system (apart from thrashing the disc
and eating nearly all of swap that is).

	I'm pretty sure that setting quotas on /var would stop this
from happening easily (enough users acting together could probably
still lay the system low).

	Not that that will make display work for this kind of file. I'd
suggest you send one of these tiff files to the ImageMagick maintainers
with a bug report - advise them to have at least 2GB of free /var space
before trying it.