abrt 1.0.7 detected a crash. architecture: x86_64 Attached file: backtrace cmdline: gs -q -sDEVICE=tiffg3 -r204x196 -dNOPAUSE -dSAFER -sOutputFile=image-0001.pnm.%03d -sPAPERSIZE=letter image-0001.pnm comment: I was sending a pdf file as a fax using efax-gtk. component: ghostscript executable: /usr/bin/gs kernel: 2.6.32.9-67.fc12.x86_64 package: ghostscript-8.71-4.fc12 rating: 4 reason: Process /usr/bin/gs was killed by signal 11 (SIGSEGV) release: Fedora release 12 (Constantine)
Created attachment 398577 [details] File: backtrace
The tiffg3 ghostscript device is missing a NULL check before calling TIFFCleanup(). However, this means that something else went wrong first. I've built a ghostscript package fixing this segfault. Could you please try it and tell me if/how it fails now? Thanks. http://koji.fedoraproject.org/koji/buildinfo?buildID=161482
hylafax still (i installed ghostscript.x86_64 8.71-4.1.fc12) doesn't work... -arne
I expected it not to work, but could you please provide some information on exactly *how* it fails? Do you get an error message, is the fax image incorrect, is a fax sent at all, are there error logs somewhere, can you get debugging information out of it, etc?
hylafax acts as if it sent everything correctly, although there were just 5 frames per page (that is for the tag line, i guess)... the kernel did not even log a segfault, also it seems to do it (at least when npviewer.bin segfault-s)... -arne
i am quite sure that ghostscript causes the problem, because: when i do this: gs -sPaperSize=A4 -dBATCH -dNOPAUSE -sOutputFile=bla.tif -sDEVICE=tiffg3 ~/deploy/docs/... (without any problem or error) and then this: tiffcp -c g3:1d:fill -r 10000 bla.tif blah.tif and then this: sendfax -n -G -d "+49 30 ..." blah.tif everything behaves like before... *wag tail* -arne
i hacked hylafax' bin/pdf2fax.gs script... this is the command that hylafax uses: /usr/bin/gs -q -sDEVICE=tiffg4 -dNOPAUSE -dSAFER=true -sPAPERSIZE=a4 -dFIXEDMEDIA -dBATCH -r209.10x196 -sOutputFile=docq/doc68.pdf;c1 docq/doc68.pdf.62 the resulting file looks good... when i force the bin/pdf2fax.gs script to use tiffg3 as -sDEVICE, then everything works fine again... so the tiffg4 device does something nasty/modern/unexpected possibly? -arne
These problems for me happened after I updated my Fedora 12 system. efax-gtk broke causing the problems on my system. I rebuilt efax-gtk adding "parms.push_back("-dMaxStripSize=0");" at line 304 in efax-gtk-3.0.20/src/efax_controller.cpp. Everything now works fine on my system. Jim Shipman
*w00t* that "-dMaxStripSize=0"-trick works for the bin/pdf2fax.gs script (in that call in the end of the script), too... -arne
The default MaxStripSize had changed from 0 in ghostscirpt-8.70 to 8192 in ghostscript-8.71. I've set it back to 0 in ghostscript-8.71-5.fc12. Could you give it a go please, without the pdf2fax.gs/efax-gtk changes? http://koji.fedoraproject.org/koji/buildinfo?buildID=161952
i just sent a fax with my unpatched hylafax and the amd64 package from http://koji.fedoraproject.org/koji/buildinfo?buildID=161952 and hylafax sent 46 frames for one page, which is much more than just the tagline... looks good to me... -arne
ghostscript-8.71-6.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/ghostscript-8.71-6.fc11
ghostscript-8.71-6.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/ghostscript-8.71-6.fc12
ghostscript-8.71-9.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/ghostscript-8.71-9.fc13
The upstream fix was to change it to 1Mb so in ghostscript-8.71-6.fc12 I've switch to that. Could you please re-test just to make sure?
but what if, that size increases to more than 1Mb? will there be again silent empty pages? or is it impossible to make a tiff file of that size and that resolution? -arne
No single TIFF page can be more than that size, and there is one strip per page.
ghostscript-8.71-6.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ghostscript'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/ghostscript-8.71-6.fc12
ghostscript-8.71-6.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ghostscript'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/ghostscript-8.71-6.fc11
ghostscript-8.71-9.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
ghostscript-8.71-6.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
ghostscript-8.71-6.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.