Package: ghostscript Version: 10.0.0~dfsg-11+deb12u8 Severity: minor X-Debbugs-Cc: [email protected]
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
