Description of problem: Tried to use hp-scan to scan a document in line mode Version-Release number of selected component (if applicable): hplip-3.14.3-1.fc19.x86_64 How reproducible: Tried only once. Have access to the system with the bug on weekends. Can provide more information at that time. Steps to Reproduce: 1. hp-scan -r 2400 -m lineart 2. Select second option (first one didn't connect, see More Info) Actual results: Scan progress bar, then core dump and segfault message. Did no see ABRT report. Expected results: Scan saved to file Additional info: Printer is an HP Deskjet 3510, connected both as USB 2 and wifi. I'd like to use the faster connection, but the choices presented by hp-scan don't indicate which is USB, and which is Wifi. Can provide console log with debugging enabled. Would need detailed instructions if gdb backtrace is needed. Is there other information I could provde? Version is possibly buggy on QA from koji. I now wish I'd made my first trial with the current version.
'hp-scan -h' says: Run in debug mode: -g (same as option: -ldebug) so that might be an option how to get more info. I'm just wondering why there was the core dump and segfault message. If it had crashed in hp-scan there should have been an backtrace because hp-scan is a python script. Maybe a problem in some python module.
HPLIP has its own Python module to provide bindings to libhpmud... I expect it's that. Please try this: su -c 'debuginfo-install hplip' gdb --args hp-scan -r 24 -m lineart Then, at the "(gdb)" prompt: run and when it crashes: thread apply all bt thread apply all info locals What output do you get?
Adding the "-g" from Comment 1, I got: "$ gdb --args hp-scan -g -r 24 -m lineart GNU gdb (GDB) Fedora 7.6.1-46.fc19 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... "/usr/bin/hp-scan": not in executable format: File format not recognized (gdb) q $ gdb --args hp-scan -r 24 -m lineart GNU gdb (GDB) Fedora 7.6.1-46.fc19 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... "/usr/bin/hp-scan": not in executable format: File format not recognized (gdb) q $"
/usr/bin/hp-scan is a link to /usr/bin/hp-scan, which is a Python script.
Created attachment 877600 [details] typescript output Ran with -g directly, not in gdb, with -g flag. Got a SANE error using USB, worked fine with wifi connection.
I think I have found the cause of the problem. When I tried the a full-page 8 1/2 X 11 in document instead of the smal envelope size I had tried previously, I ran out of disk space. df showed I had exhausted my 3.6G /tmp. That's surprising, for I would expect the 500M pixel document (echo $((850*11*2400*2400/1024/1024)) gives 51361) to take half a gig in lineart, assuming 1 byte per pixel. The script should warn the user how much disk space is required, and give a warning instead of running out of space on /tmp, potentially crippling the whole system. Also, there should also a way to specify a disk other than /tmp for temporary storage. I didn't see a way to do that in "hp-scan -h". To see if I could modify the python code, I tried: "$ grep tmp /usr/bin/hp*", and got "/usr/bin/hpcups-update-ppds:trap 'rm -f "$tmpdir"/models; rmdir "$tmpdir"; exit 0' \ /usr/bin/hpcups-update-ppds:tmpdir="$(mktemp -d)" /usr/bin/hpcups-update-ppds: if [ ! -f "$tmpdir/models" ] /usr/bin/hpcups-update-ppds: lpinfo -h "$sock" --include-schemes=drv -m 2>/d ev/null >"$tmpdir/models" /usr/bin/hpcups-update-ppds: done <"$tmpdir/models" Binary file /usr/bin/hpijs matches /usr/bin/hp-logcapture:TMP_DIR = "/var/spool/cups/tmp" /usr/bin/hp-logcapture: TMP_DIR = "/tmp" /usr/bin/hp-logcapture: log.error("Failed to remove hpcupsfilter tmp files.") /usr/bin/hp-logcapture: log.error("Failed to remove hpcups tmp files.") /usr/bin/hp-logcapture: log.error("Failed to remove hpliptiff tmp files.") /usr/bin/hp-logcapture: log.error("Failed to remove hpcups tmp files.") /usr/bin/hp-scan: tmp = dest_devUri.partition(":")[2] /usr/bin/hp-scan: dest_devUri = "hp:" + tmp " I don't see an obvious patch here.
At 1200 dpi, the scan works fine. The size of the temporary file on /tmp is about 500M. I found a number of simple-scan bugs when I first filed this report. Maybe they are also running into the problem of exhausting /tmp.
OK, the first easy thing to change is for it to use /var/tmp by default instead of /tmp.
Created attachment 882782 [details] hplip-scan-tmp.patch This is intended to do that.
Got an AVC alert when I updated an FC20 system: SELinux is preventing /usr/sbin/cupsd from write access on the file . ***** Plugin catchall (100. confidence) suggests ************************** If you believe that cupsd should be allowed write access on the file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep cupsd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:cupsd_t:s0-s0:c0.c1023 Target Context unconfined_u:object_r:cupsd_etc_t:s0 Target Objects [ file ] Source cupsd Source Path /usr/sbin/cupsd Port <Unknown> Host localhost.localdomain Source RPM Packages cups-1.7.1-8.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-135.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 3.13.7-200.fc20.x86_64 #1 SMP Mon Mar 24 22:01:49 UTC 2014 x86_64 x86_64 Alert Count 2 First Seen 2014-04-05 11:39:19 EDT Last Seen 2014-04-05 11:39:21 EDT Local ID 020fa408-60d2-41aa-8b66-45d244a86ca3 Raw Audit Messages type=AVC msg=audit(1396712361.578:668): avc: denied { write } for pid=460 comm="cupsd" name="HP-Deskjet-3510-wifi.ppd" dev="sda9" ino=915207 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:cupsd_etc_t:s0 tclass=file type=SYSCALL msg=audit(1396712361.578:668): arch=x86_64 syscall=open success=no exit=EACCES a0=7fff80e4e1b0 a1=1 a2=1b6 a3=7faa1c7487e0 items=0 ppid=1 pid=460 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=cupsd exe=/usr/sbin/cupsd subj=system_u:system_r:cupsd_t:s0-s0:c0.c1023 key=(null) Hash: cupsd,cupsd_t,cupsd_etc_t,file,write
Tried running hp-scan -3.14.3-2.fc19.x86_64 . The program seemed to run fine, but it used /tmp and not /var/tmp for temporary storage. I had set "-g" in my invocation of hp-scan, and the tail of the output was: "hp-scan[8491]: debug: Read 71558100 bytes hp-scan[8491]: debug: Read 71560650 bytes hp-scan[8491]: debug: Read 71563200 bytes hp-scan[8491]: debug: Scan thread exiting... Read 68.2 MB from scanner. hp-scan[8491]: debug: PPL=20400 lines=28064 depth=1 BPL=2550 pad=0 total=71563200 Segmentation fault (core dumped) " So, not much more information.
Created attachment 885885 [details] typescript with default options. contains cursor codes. Discovered -v option in python to get a trace. Tried with default options, runs fine. Printer cover was closed, with nothing on the flatbed.
Created attachment 885886 [details] typescript with -m lineart -r 2400, contains cursor codes Tried again with -m lineart and -r 2400. It took considerably longer. I abreviated the typescript to remove most of of the -g bytes read messages. The segfault occurs right after the scan, but I saw no further clues in the python -v trace.
hplip-3.14.4-4.fc19 should fix the "scanning to /tmp" issue for good. Does it still segfault?
hplip-3.14.4-4.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/hplip-3.14.4-4.fc20
Package hplip-3.14.4-4.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing hplip-3.14.4-4.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6291/hplip-3.14.4-4.fc20 then log in and leave karma (feedback).
Package hplip-3.14.4-5.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing hplip-3.14.4-5.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6291/hplip-3.14.4-5.fc20 then log in and leave karma (feedback).
Package hplip-3.14.6-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing hplip-3.14.6-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6291/hplip-3.14.6-1.fc20 then log in and leave karma (feedback).
Package hplip-3.14.6-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing hplip-3.14.6-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6291/hplip-3.14.6-2.fc20 then log in and leave karma (feedback).
hplip-3.14.6-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 916531 [details] typescript with debugging No segfault, but still doesn't work. Please reopen.
I think you're seeing a problem with the fix for bug #987167 there. Fix coming up.
Please try hplip-3.14.6-3: http://koji.fedoraproject.org/koji/buildinfo?buildID=542792 (Fedora 19) http://koji.fedoraproject.org/koji/buildinfo?buildID=542791 (Fedora 20)
Created attachment 916758 [details] condensed typescript file 1) Now picks up default printer choice, scans, but still gets segfault. ABRT doesn't show anything. 2) A essage states 500M file will be generated, but doesn't warn about the 2.2G file I noticed on /var/tmp. 3) Since the temp file is so large, and the scan takes so long, it would be nice to have a switch to specify its location, and for the scanning program to check if the space is sufficient.
Please do the following in order to get more information about the segfault: sudo debuginfo-install hplip gdb --args /usr/bin/python /usr/bin/hp-scan -r 2400 -m lineart -g Then at the '(gdb)' prompt: run When the program crashes, enter: thread apply all bt
Thanks for the incredibly quick response. Unfortunately, I won't be able to try again until next weekend.
Created attachment 917625 [details] requested debuginfo output Here is the requested gdb output. gdb is asking for additional debugging packages to be installed. Do you need another run with those installed?
Created attachment 917631 [details] requested debuginfo output Found I only needed a couple of debuginfos because the others were already installed. Here is another run, with the debugging installations out of the way.
Created attachment 917635 [details] requested debuginfo output Was missing hplip-libs debuginfo. Installed that and ran again.
Created attachment 917636 [details] requested debuginfo output Didn't do both thread info commands. Hope this is the last for now.
This seems to be coming from Image.convert() in PIL: scan.py: im = Image.frombuffer('RGBA', (pixels_per_line, lines), buffer.read(), 'raw', 'RGBA', 0, 1).convert('L') Changing component.
In scan.py, I see log.debug("PPL=%d lines=%d depth=%d BPL=%d pad=%d total=%d" % (pixels_per_line, lines, depth, bytes_per_line, pad_bytes, total_read)) before the Image.frombuffer call. Do you see corresponding text when running the script in debug mode? Could you post the output?
I'm not familiar with python, let alone debugging scripts in it. Please provide explicit instructions, in the style of comment 25.
See attachment from comment #30, line 28156: hp-scan[30127]: debug: PPL=20400 lines=28064 depth=1 BPL=2550 pad=0 total=71563200
Ah right thanks.
I wonder how 'RGBA' can possibly work here? According to the debug output and the code around the Image.frombuffer call, the buffer is a monochrome, 1bit per pixel image (i.e. PixelsPerLine / 8 = BytesPerLine), whereas RGBA means 4 bytes per pixel. Newer python-pillow (rawhide for sure, but if I remember correctly should be as of F20+) will throw exceptions if the buffer is to small, the version in F19 does not, and hence the crash. Indeed, something like lines=28064 pixels_per_line=20400 total=71563200 buf = bytearray(total) im = Image.frombuffer('RGBA', (pixels_per_line, lines), buf, 'raw', 'RGBA', 0, 1).convert('L') segfaults on F19, but on rawhide, an exception is thrown. So this does not look like a pillow issue.
Created attachment 920201 [details] hplip-lineart.patch (potential fix) So maybe changing RGBA to 1 would fix it?
Please try this build: https://koji.fedoraproject.org/koji/buildinfo?buildID=547231
The patch in comment 38 is for FC20. I'll have acces to the printer with the problem on Friday, July 25, and I can test with a laptop at FC20. However, the computer with the problem is as FC19, so I'll need a build for that version, too.
Yep changing RGBA to 1 should work (though I also don't currently have a scanner to test).
Here's a Fedora 19 build to try: http://koji.fedoraproject.org/koji/buildinfo?buildID=547654
Created attachment 921170 [details] typescript output Tried hplip-3.14.6-6.fc19.x86_64 as per comment 25. Seemed to scan, but then it was using 6-7 GB of main memory, and 20 GB of swap, and did not seem to terminate. I used CTRL-C and requested a backtrace. Will run again after installing missing debuginfos. Noticed a number of CRC warnings from gdb.
Created attachment 921228 [details] typescript output with all debuginfos Downloaded the debuginfos and ran again. Memory hogging started after the following: "207 ^[[34;01mhp-scan[13726]: debug: Lineart Read 71563200 bytes^[[0m^M 208 ^[[34;01mhp-scan[13726]: debug: Scan thread exiting...^[[0m^M 209 [Thread 0x7fffe3244700 (LWP 13764) exited]^M 210 ^M 211 Read 68.2 MB from scanner.^M 212 ^[[34;01mhp-scan[13726]: debug: PPL=20400 lines=28064 depth=1 BPL=2550 pad=0 total=71563200^[[0 m^M 213 Closing device.^M 214 Detaching after fork from child process 14003.^M 215 Detaching after fork from child process 14005.^M 216 ^C^M 217 Program received signal SIGINT, Interrupt.^M " As the remainder of the attachment shows, I took a trace after hitting CTRL-C, line 217. I was using about 7G of main memory (almost all of it), and 3G of swap.
Looks like it was trying to show a traceback for exceptions.OverflowError('size does not fit in an int',). Not really sure what the correct fix is. I've reported it upstream.
Since hplip has been updated, I tried a fresh run today. I have hplip-3.14.6-6.fc19.x86_64 and python-2.7.5-13.fc19.x86_64 Behaviour is as in comment 43. I am attaching an abridged typescript. It's a bit messy because I installed the missing debuginfos in another window, and then tried to include their names in the gdb session. I didn't try to get a cleaner session because I believe it necessary to await the upstream correction.
Created attachment 935015 [details] abreviated gdb typescript Oops, forgot to attach the typescript mentioned above.
Got comment 43 behaviour in FC20 with hplip-3.14.6-5.fc20.x86_64 . I ran without gdb.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.