Bug 850826
Summary: | [abrt] sane-backends-1.0.22-11.fc17: ipConvert: Process /usr/bin/scanimage was killed by signal 11 (SIGSEGV) | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jeff Layton <jlayton> | ||||||||
Component: | hplip | Assignee: | Tim Waugh <twaugh> | ||||||||
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | unspecified | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 17 | CC: | jpopelka, nphilipp, steved, twaugh | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | x86_64 | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | abrt_hash:95b98c5120410bc4167676aba4594ae3d78b6a32 | ||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2012-09-04 14:25:05 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Jeff Layton
2012-08-22 13:40:23 UTC
Created attachment 606278 [details]
File: backtrace
Created attachment 606279 [details]
File: maps
Created attachment 606280 [details]
File: dso_list
*** Bug 817922 has been marked as a duplicate of this bug. *** FWIW, downgrading to libsane-hpaio-3.11.12-2.fc17.x86_64 resolves the problem. The crash happens here in ip/ipmain.c:791: HANDLE_TO_PTR (hJob, g); This macro is defined in ip/ipdefs.h: #define HANDLE_TO_PTR(hJob_macpar, inst_macpar) \ do { \ inst_macpar = (void*)hJob_macpar; \ INSURE (inst_macpar->dwValidChk == CHECK_VALUE); \ } while (0) I guess that dereferencing inst_macpar->dwValidChk segfaults, but that's just a hunch. Changing component to hplip. The value of hJob=0x2207615113064131 doesn't look like a correct pointer value. It also has the exactly same value in backtrace in bug #817922. Anyway, the trace to the crash is: scan/sane/soapht.c::soapht_start() | \/ scan/sane/soapht.c::get_ip_data(ps) | \/ ip/ipmain.c::ipConvert(hJob=ps->ip_handle) | \/ ip/ipdefs.h::HANDLE_TO_PTR(hJob, g) and it's strange that the HANDLE_TO_PTR crashed in ipConvert(), while it was called a few times before in soapht_start() (in ipSetDefaultInputTraits(ps->ip_handle) or ipResultMask(ps->ip_handle)) and I can't find any trace of ps->ip_handle being changed between these calls. Jeff, could you try running scanimage under valgrind? 1. First, install hplip-debuginfo: yum --enablerepo=updates-debuginfo install hplip-debuginfo 2. Then run valgrind: valgrind scanimage -d 'hpaio:/net/HP_LaserJet_CM1415fnw?ip=192.168.1.10' -T When I run it here I see two warnings about http_read() -- but they wouldn't cause what you're seeing so they can be ignored. What output do you get? Here's what I get: $ valgrind scanimage -d 'hpaio:/net/HP_LaserJet_CM1415fnw?ip=192.168.1.10' -T ==7689== Memcheck, a memory error detector ==7689== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==7689== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==7689== Command: scanimage -d hpaio:/net/HP_LaserJet_CM1415fnw?ip=192.168.1.10 -T ==7689== ==7689== Conditional jump or move depends on uninitialised value(s) ==7689== at 0x1211359B: get_tag (xml.c:72) ==7689== by 0x1210FAB7: parse_scan_elements (bb_soapht.c:230) ==7689== by 0x12111ED6: get_scanner_elements (bb_soapht.c:682) ==7689== by 0x1211227E: bb_open (bb_soapht.c:790) ==7689== by 0x7B8E922: soapht_open (soapht.c:504) ==7689== by 0x7B86FAA: sane_hpaio_open (hpaio.c:338) ==7689== by 0x4C44422: sane_dll_open (dll.c:1199) ==7689== by 0x10A4B0: main (scanimage.c:1998) ==7689== ==7689== Conditional jump or move depends on uninitialised value(s) ==7689== at 0x121135B3: get_tag (xml.c:74) ==7689== by 0x1210FAB7: parse_scan_elements (bb_soapht.c:230) ==7689== by 0x12111ED6: get_scanner_elements (bb_soapht.c:682) ==7689== by 0x1211227E: bb_open (bb_soapht.c:790) ==7689== by 0x7B8E922: soapht_open (soapht.c:504) ==7689== by 0x7B86FAA: sane_hpaio_open (hpaio.c:338) ==7689== by 0x4C44422: sane_dll_open (dll.c:1199) ==7689== by 0x10A4B0: main (scanimage.c:1998) ==7689== ==7689== Invalid read of size 4 ==7689== at 0x7DB28EB: ipConvert (ipmain.c:791) ==7689== by 0x7B8D25A: get_ip_data (soapht.c:188) ==7689== by 0x7B8F375: soapht_start (soapht.c:1052) ==7689== by 0x10B4F4: main (scanimage.c:1541) ==7689== Address 0x2207615113065265 is not stack'd, malloc'd or (recently) free'd ==7689== ==7689== ==7689== Process terminating with default action of signal 11 (SIGSEGV) ==7689== General Protection Fault ==7689== at 0x7DB28EB: ipConvert (ipmain.c:791) ==7689== by 0x7B8D25A: get_ip_data (soapht.c:188) ==7689== by 0x7B8F375: soapht_start (soapht.c:1052) ==7689== by 0x10B4F4: main (scanimage.c:1541) ==7689== ==7689== HEAP SUMMARY: ==7689== in use at exit: 764,785 bytes in 13,953 blocks ==7689== total heap usage: 31,262 allocs, 17,309 frees, 2,054,057 bytes allocated ==7689== ==7689== LEAK SUMMARY: ==7689== definitely lost: 4,484 bytes in 2 blocks ==7689== indirectly lost: 0 bytes in 0 blocks ==7689== possibly lost: 0 bytes in 0 blocks ==7689== still reachable: 760,301 bytes in 13,951 blocks ==7689== suppressed: 0 bytes in 0 blocks ==7689== Rerun with --leak-check=full to see details of leaked memory ==7689== ==7689== For counts of detected and suppressed errors, rerun with: -v ==7689== Use --track-origins=yes to see where uninitialised values come from ==7689== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 2 from 2) Segmentation fault (core dumped) From a naive look at this code, it looks like get_ip_data passed in a bogus (maybe uninitialized?) hJob pointer to ipConvert. That seems to come from ps->ip_handle (where ps is the struct soap_session). I assume that the soap_session gets allocated in create_session() and should therefore be initialized to 0 there. From there, it looks like that should get set in ipOpen via: IP_MEM_ALLOC (sizeof(INST) + nClientData, g); *phJob = g; ...while the code is pretty wrapper-heavy and hard to follow, I don't see any obvious bugs. Perhaps something else is scribbling over this value? (In reply to comment #10) > Perhaps something else is scribbling over this value? Seems to. From this code: ipResultMask(ps->ip_handle, IP_PARSED_HEADER); while (1) { ret = get_ip_data(ps, NULL, 0, NULL); ... // nothing touches ps->ip_handle here } it must be something in get_ip_data, because the ipResultMask(ps->ip_handle,...) also calls HANDLE_TO_PTR(hJob, g) and it's OK. get_ip_data() calls bb_get_image_data(ps) which is a function from dynamically loaded plugin. I think this could be the source of the ps->ip_handle ravaging. (In reply to comment #11) > bb_get_image_data(ps) which is a function from dynamically loaded plugin If I read the bb_load() in soapht.c correctly the plugin should be /usr/share/hplip/scan/plugins/bb_soapht.so which is not provided by any package. It's the proprietary plugin, installed via hp-plugin, so there's nothing we can do here, except reporting it upstream. Good call -- there must have been some sort of subtle ABI breakage between hplip-3.11 and 3.12 I reran hp-check-plugin and it downloaded a newer version of the binary goop which doesn't cause the segfault. I think we can close this as NOTABUG. Now if I just had some way to monitor whether their binary junk was out of date without needing some stupid tray icon, I'd be set... Thanks for the help! Now that I look, I think the main problem was that I had the 3.11 version of the plugin, which didn't work correctly with the 3.12 open-source parts. I wonder if we should have some sort of check in the postinstall scriptlet that looks for that sort of incompatibility? Reported upstream: https://bugs.launchpad.net/hplip/+bug/1048691 |