Since commit #ab767c, which must have been roughly around the time when 2.6.0 was released IIRC, gscan2pdf wouldn't start up properly for me anymore. It would only show a blank window without any GUI elements whatsoever, hanging on the commandline with the following error message:
[zlatko@disclosure:~/usrlocal/src/gscan2pdf]$ ./gscan2pdf --log=file.log INFO - Starting gscan2pdf 2.9.0 INFO - Called with perl -I /usr/local/lib/perl5/site_perl -I /usr/local/lib/perl5 -I /usr/local/lib/perl5/site_perl/i386-linux -I /usr/local/stow/Perl-0-perllocal.pod/lib/perl5/i386-linux -I /usr/local/lib/perl5/site_perl/5.8.7/i486-linux -I /usr/local/lib/perl5/site_perl/5.8.6/i486-linux -I /usr/local/lib/perl5/site_perl/5.8.4/i486-linux -I /usr/local/stow/Perl-0-perllocal.pod/lib/perl5/5.10.0/i486-linux-thread-multi -I /usr/local/stow/Perl-0-perllocal.pod/lib/perl5/5.10.0/i486-linux-thread-multi -I /usr/local/stow/Perl-0-perllocal.pod/lib/perl5/5.10.0/i486-linux-thread-multi -I /usr/local/lib/perl5/site_perl/5.10.0/i486-linux-thread-multi -I /usr/local/lib/perl5/site_perl/5.10.0/i486-linux -I /usr/local/lib/perl5/site_perl/5.10.0 -I /usr/local/lib/perl5/site_perl/5.8.8/i486-linux-thread-multi -I /usr/local/lib/perl5/site_perl/5.8.8/i486-linux -I /usr/local/lib/perl5/site_perl/5.8.8 -I /usr/local/lib/perl5/5.10.0/i486-linux-thread-multi -I /usr/local/stow/Perl-0-perllocal.pod/lib/perl5/5.10.0/i486-linux-thread-multi -I /usr/local/lib/perl5/5.10.0 -I /usr/local/stow/Perl-0-perllocal.pod/lib/perl5/5.10.0/i486-linux-thread-multi -I /usr/local/stow/Perl-0-perllocal.pod/lib/perl5/5.10.0/i486-linux-thread-multi -I /usr/local/stow/Perl-0-perllocal.pod/lib/perl5/5.10.0 -I /usr/local/share/perl5 /usr/local/src/gscan2pdf/gscan2pdf --log=/usr/local/src/gscan2pdf/file.log INFO - Log level DEBUG INFO - Using de_AT.UTF-8 locale INFO - Startup LC_NUMERIC C INFO - Reading config from /home/zlatko/.config/gscan2pdfrc INFO - Config file version v2.9.0 [...] INFO - convert rose: /tmp/gscan2pdf-OIHl/DJ2Rx48MXr.tif INFO - Spawned PID 21386 WARN - *** unhandled exception in callback: *** Negative length at /usr/lib/perl5/IO/Handle.pm line 463. *** ignoring at /usr/local/lib/perl5/Glib/Object/Introspection.pm line 67. ^C [zlatko@disclosure:~/usrlocal/src/gscan2pdf]$
With a few debug print
s I found out the the error occurs at line 958, after calling my $imgobj = $pdfobj->image_tiff($temptif);
, but I'm not Perl-fluent enough to dig any deeper. It was easier for me to create a simple patch to revert commit #ab767c instead, and have it use tiff2pdf
during the dependency check like before. :-) I haven't noticed any problems since then during actual usage, generating and saving PDFs works fine as usual, it was just the dependency check on startup that didn't work.
The full file.log
is attached, maybe it helps to shed some light.
And yes, I know ... sorry for my $PERLPATH
from hell. :-D I have accumulated tons of modules in /usr/local
from many different Perl versions included in many different Slackware releases over the years, and my $PERLPATH
shows. I do however update & recompile those that make use of shared objetcs whenever I notice that they don't work anymore, so I'm pretty sure that this isn't part of the problem. Feel free to prove me wrong, though. ;-)
And last but not least: thanks for a great piece of software! :-)
Thanks for the report.
The weird thing is that the code you debugged is also used in a more complicated form when creating PDFs with LZW, Zip or Packbits compression. Perhaps you've never tried those options. Can you?
I'm guessing that the problem must be somewhere inside PDF::API2.
You can get a better backtrace with the perl debugger:
It'll then prompt before starting the program. Type
r
to run it. When it crashes, typeT
for a backtrace, and thenq
to quit.I'm interested how you have installed the program.
/usr/local/src/gscan2pdf/gscan2pdf
looks like you've dumped the source there, but in that case, there would normally be abin
directory. What is in/usr/local/src/gscan2pdf
?The strange "installation" in
/usr/local/src/gscan2pdf/gscan2pdf
was only used for this report, I just copied the main "binary" there as I was too lazy to reverse-patch my actual installation in its original folder. Probably not a good idea, as it obviously created some confusion/irritation here. Sorry about that!The (rest of the) actual installation lives in
/usr/local/stow/gscan2pdf-2.9.0
, which is then symlinked back to the/usr/local/
hierarchy using - yes, you guessed it ;-) - GNUstow
. I now added the unpatched main "binary" to the normal location usinggscan2pdf-unpatched
as a name, and I'll use this one for further debugging from now on. The symlink indirection bystow
and my$PERLPATH
already cause more than enough obfuscation anyway. I'll probably also try to also cut down my$PERLPATH
to contain only the things needed forgscan2pdf
to get rid of unneeded cruft.I'll report back here as soon as I found something, eiter a crash in the compression options you mentioned, or a usable backtrace from the
perl -d
run.Thanks! :-)
Wow, you were spot-on with your assumption that the problem is within PDF::API2. I created a minimalistic
test.pl
consisting only of the failing code block:I then created
/tmp/test.tif
exactly the same way it is created ingscan2pdf
:Ready, set, go:
Ho-hum. I then tested this script with a few other TIFFs I had lying around, and they all did not cause this error. I then used
convert
to create a JPG instead of a TIFF, and this did also not cause the error. The TIFF was also displayed fine inxv
,gimp
,eog
,gthumb
andgeequie
, and neither of these viewers showed any warning that something might be wrong with the image.So the problem appears to be two-fold: (my version of)
convert
creates a possibly somehow out-of-specs TIFF, and PDF::API2 crashes on reading it instead of handling it gracefully. Or it hits some obscure corner case in its TIFF loading code. I stepped through it once in the debugger, and it appears to read the file in 12-byte-chunks. The size of theconvert
-created TIFF is not a multiple of 12 bytes. I checked a couple (but not all, only three or so) of the other TIFFs, and all of their sizes were multiples of 12 bytes.Could this be it, something so simple and stupid? I'll attach my
test.tif
so you can compare it to the one that your version ofconvert
creates. I'll try to find & dig into the TIFF specs a bit meanwhile. Possibly relevant information:Last edit: Thomas Zajic 2020-09-23
Hmm. I've found bugs in PDF::API2's TIFF implementation before, which is why I wrote Graphics::TIFF to allow PDF::API2 to use libtiff directly to access the images rather than reinventing the wheel. Unfortunately, the author didn't bite, despite my giving him the patches necessary.
Another guy forked PDF::API2 to PDF::Builder, and has used my patches, so the next release of gscan2pdf will probably use PDF::Builder.
Back to your problem - you are right - JPEG is much better tested than TIFF in PDF::API2. I only kept the TIFF out of laziness because I was using tiff2pdf before to create the test PDF.
I'll change to testing with a JPEG and your problem should disappear.
Okay, thanks a lot. I've already seen the patches you mentioned in CPANs RT, while I was looking for bug reports against PDF::API2 which could be related to this one.
I meanwhile also tried the
convert rose: test.tif
thing on an FC32 workstation using a newer version of IM & convert. Thetest.tif
it created was in fact 8 bytes smaller in size, and thus its size was a multiple of 12. This file was happily accepted by PDF::API2 and didn't cause an error.So it looks like it really was a combination of a "slightly unusual" TIFF and PDF::API2's non-existent error handling of such a case. Oh well. Feel free to close this ticket, and thanks for your efforts! :-)
I've just committed this patch, which should fix things for you.