Bug#1118144: ghostscript: No space left on /tmp causes unclear "Unable to get scanline 0!" error message
Package: ghostscript
Version: 10.0.0~dfsg-11+deb12u8
Severity: minor
X-Debbugs-Cc: cjp@ultimatestunts.nl
Dear Maintainer,
See bug 1118061 in CUPS[1].
I discovered that, when using "gs" to convert a PDF to CUPS' raster format, a
lack of space on /tmp causes the very unclear error message "Unable to get
scanline 0!". The gs command was:
cat <pdffile> | gs -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=cups
-r360x360 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=841 -dcupsBitsPerColor=8
-f -_
Note that this worked for some PDFs, but it failed for one particular PDF,
which I cannot share for privacy reasons. I suspect you can reproduce the error
with almost any PDF just by making available space on /tmp really small (the
failing system only had 20MB in /tmp). In my experience, the
-dcupsBitsPerColor=8 argument is relevant; maybe gs requires less space on /tmp
without it.
I discovered that the error message was linked to /tmp by running gs inside
strace, and comparing the strace output with the output on a system where gs
was successful. Strace on the failing system showed several write commands that
returned -1 ENOSPC, and the file descriptor corresponded to a file in /tmp.
This theory was proved when I increased space in /tmp, and the error message
disappeared.
With insufficient space on /tmp, I *expect* ghostscript to fail with an error
message, but this error message was very unclear. Before doing the strace, I
tried to debug the error with gdb, but the results were misleading. I tried to
search for causes-of-causes-of-causes, and gave up at the point where I traced
it back to gsicc_search_icc_table returning -1, indicating a problem with ICC
profiles. I guess this problem was somehow caused by the lack of space on /tmp,
but I don't know how.
I guess this should be fixed in ghostscript by checking whether writes to
(temporary) files succeed; in case of error, a message like "Could not
write to <filename>: no space left on device" would be appropriate.
kind regards,
CJP
PS. the system information attached is for my laptop, while the bug occurred on
a Raspberry Pi. Please ignore the system information. I believe There's no much
need
for it anyway; the main way to reproduce the bug should be to have insufficient
space in /tmp.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1118061
-- System Information:
Debian Release: 12.12
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-debug'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-40-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages ghostscript depends on:
ii libc6 2.36-9+deb12u13
ii libgs10 10.0.0~dfsg-11+deb12u8
ghostscript recommends no packages.
ghostscript suggests no packages.
-- no debconf information
Reply to: