gscan2pdf / Bugs / #319 gscan2pdf crashes with error message: perl: unable to extent pixel cache `No such file or directory' @ fatal/cache.c/CacheSignalHandler/3626

Faheem Mitha - 2019-04-07

Also note that searching for

fatal/cache.c/CacheSignalHandler/3626

gives hits for Imagemagick, which does not seem like a coincidence., though I was not aware
that gscan2pdf depended on Imagemagick.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jeffrey Ratcliffe - 2019-04-08

gscan2pdf uses imagemagick for all the image operations - conversions and the like.

You are right, this looks like an imagemagick memory problem.

Therefore, I assume you can workaround the problem by scanning a smaller area, or using a lower resolution.

As well as helping you get imagemagick working, I'd like to have gscan2pdf not crash, and produce a reasonable error message.

What is in your /etc/ImageMagick-6/policy.xml ?

By default, the first thing that happens after scanning an image is that it is converted to PNG to reduce the space used and add some metadata. What happens if you switch off the "convert scanned images to PNG before further processing" in Edit/Preferences/General options ?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Faheem Mitha - 2019-04-08
  
  Hi Jeffrey,
  
  Here's hoping that replying via email works.
  
  On Mon, 8 Apr 2019, Jeffrey Ratcliffe wrote:
  
  gscan2pdf uses imagemagick for all the image operations - conversions and the like.
  
  I eee. I didn't know that.
  
  You are right, this looks like an imagemagick memory problem.
  
  Ok.
  
  Therefore, I assume you can workaround the problem by scanning a smaller
  area, or using a lower resolution.
  
  As well as helping you get imagemagick working, I'd like to have
  gscan2pdf not crash, and produce a reasonable error message.
  
  What is in your /etc/ImageMagick-6/policy.xml ?
  
  It's the default for Debian stable. I haven't changed anything. Attached -
  here's hoping email attachments convert to ticket attachments.
  
  By default, the first thing that happens after scanning an image is that
  it is converted to PNG to reduce the space used and add some metadata.
  What happens if you switch off the "convert scanned images to PNG before
  further processing" in Edit/Preferences/General options ?
  
  It works ok with that option off. If I switch it on again, it promptly
  crashes. Is that helpful? I'm attaching the log file first with that
  option off (no crash), and then with that option on (crash).
  
  If these attachments don't find their way into the bug report, I'll add
  them manually.
  
  BTW, on a tangentially related note, someone recently told me that
  SourceForge was "an unusable pile of garbage". Since you're still using
  it, just wonder what you think.
  
  [bugs:#319] gscan2pdf crashes with error message: perl: unable to extent pixel cache `No such file or directory' @ fatal/cache.c/CacheSignalHandler/3626
  
  Status: open
  Group: v1.0_(example)
  Created: Sun Apr 07, 2019 07:47 PM UTC by Faheem Mitha
  Last Updated: Sun Apr 07, 2019 07:53 PM UTC
  Owner: nobody
  Attachments:
  
  gscan2pdf.log (182.9 kB; text/x-log)
  
  Hi Jeffrey,
  
  Another day, another bug.
  
  I'm seeing crashes with both the current version in Debian
  experimental (2.5.1-1), and the current version in Debain unstable
  (2.3.0-1). The report before is for 2.5.1-1. The error messages in
  both cases look identical.
  
  The bit immediately before the crash looks like:
  
  INFO - Scanning 0 pages from 1 with step 1
  DEBUG - signal 'started-process' emitted with message: Scanning page 2
  DEBUG - signal 'finished-process' emitted with data: scan_pages
  perl: unable to extent pixel cache No such file or directory' @ fatal/cache.c/CacheSignalHandler/3626. perl: unable to extent pixel cacheSuccess' @ fatal/cache.c/CacheSignalHandler/3626.
  
  I did the usual
  
  gscan2pdf --log=/tmp/gscan2pdf.log
  
  The log ends with
  
  DEBUG - signal 'finished-process' emitted with data: scan_pages
  
  So the last two lines starting with perl: do not appear in the log.
  
  I was trying to scan at 600 dpi on the gray setting with my Brother
  DCP-7065DN flatbed. I'm pretty sure I've never tried to do that
  before, but of course I can't be sure this setting is related to the
  crash. But I don't recall seeing any crashes before, and I was seeing
  crashing more of less immediately after I tried using that setting.
  
  Log attached.
  
  Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/gscan2pdf/bugs/319/
  
  To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
  
  Related
  
  Bugs: #319
  
  gscan2pdf.log
  
  policy.xml
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jeffrey Ratcliffe - 2019-04-10

Here, it looks as though imagemagick is running out of tmp:

https://www.imagemagick.org/discourse-server/viewtopic.php?t=25064

Having scanned the image without the to-png option, please copy it out of the /tmp/gscan2pdf-xxxx directory to somewhere it won't get deleted, and see if you can reproduce the problem from the command file:

convert test.pnm test.png

If that produces the same error,

df

Might tell where you are short of space and

convert -debug cache test.pnm test.png

might give more info.

"Unusable" is a little harsh and, at least for me, inaccurate. I don't see the advantage (to me) of moving the project to (say) github.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Faheem Mitha - 2019-04-10
  
  Hi Jeffrey,
  
  On Wed, 10 Apr 2019, Jeffrey Ratcliffe wrote:
  
  Here, it looks as though imagemagick is running out of tmp:
  
  https://www.imagemagick.org/discourse-server/viewtopic.php?t=25064
  
  Having scanned the image without the to-png option, please copy it out
  of the /tmp/gscan2pdf-xxxx directory to somewhere it won't get deleted,
  and see if you can reproduce the problem from the command file:
  
  convert test.pnm test.png
  
  If that produces the same error,
  
  df
  
  Might tell where you are short of space and
  
  convert -debug cache test.pnm test.png
  
  might give more info.
  
  Yes, it's probably running out of space in /tmp.
  
  As it happens, I was trying to backport the Gimp 2.10.8 Debian source from
  unstable to stable yesterday. The tests run during build were producing
  mysterious errors, but that's another story. Anyway, the build crapped out
  towards the end, because it ran out of space on /, which also contains
  /tmp. So I removed a bunch of old and obsolete packages (Debian lets old
  and obsolete packages in many cases hang around indefinitely, gcc,
  clang/LLVM, for example). So now I have around 3.1 GB free, and it
  probably won't show the same problem. But I'll try your instructions in a
  bit. Of course, I could temporarily reduce the amount of space available
  on / and see if I can reproduce.
  
  In any case, the message produced is really unclear.
  
  Have you tested with an inadequate amount of /tmp space to see what will
  happen?
  
  "Unusable" is a little harsh and, at least for me, inaccurate. I don't
  see the advantage (to me) of moving the project to (say) github.
  
  Yes, GH is the new hotness. Everyone and their cousin is on it.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

gscan2pdf crashes with error message: perl: unable to extent pixel cache `No...

Group

Searches

Help

#319 gscan2pdf crashes with error message: perl: unable to extent pixel cache `No such file or directory' @ fatal/cache.c/CacheSignalHandler/3626

Related

Discussion

Related