Bug 1882520 - Crash on libsane-airscan when trying to activate scanner
Summary: Crash on libsane-airscan when trying to activate scanner
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sane-airscan
Version: 32
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Zdenek Dohnal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-09-24 19:31 UTC by thranur
Modified: 2020-11-09 05:42 UTC (History)
4 users (show)

Fixed In Version: sane-airscan-0.99.17-1.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-17 14:08:37 UTC
Type: Bug


Attachments (Terms of Use)
stack trace (with gdb 'bt f' and debug packages) of segmentation fault in airscan, when running skanlite (16.00 KB, text/plain)
2020-09-29 20:41 UTC, thranur
no flags Details
log generated after enabling trace on /etc/xsane.d/airscan.conf and running xsane (6.78 KB, text/plain)
2020-10-01 20:43 UTC, thranur
no flags Details
log generated by 'valgrind --leak-check=full --log-file=valgrind_log xsane' while connected to wifi (252.21 KB, text/plain)
2020-10-01 20:53 UTC, thranur
no flags Details

Description thranur 2020-09-24 19:31:56 UTC
Description of problem:
Unable to use scanner due to crash happening with callstack implicating libsane-airscan.

The scanner itself is a Canon Pixma TS 5055, but the error happens even when not connected.

With skanlite, I get the following callstack, after trying to open the application (as reported by Dr. Konqi):

Thread 6 (Thread 0x7f2d95da6700 (LWP 3508668)):
[KCrash Handler]
#4  0x00007f2db6c3a731 in __strstr_sse2_unaligned () from /lib64/libc.so.6
#5  0x00007f2d9c1caf10 in http_query_set_host () from /usr/lib64/sane/libsane-airscan.so.1
#6  0x00007f2d9c1cba2f in http_query_start_processing () from /usr/lib64/sane/libsane-airscan.so.1
#7  0x00007f2d9c1ccf8c in eloop_thread_func () from /usr/lib64/sane/libsane-airscan.so.1
#8  0x00007f2db6415432 in start_thread () from /lib64/libpthread.so.0
#9  0x00007f2db6c92913 in clone () from /lib64/libc.so.6


With xsane-gimp (Gimp -> Create -> XSane: Device Dialog...), the same callstack:

#0  0x00007ffff7449731 in __strstr_sse2_unaligned () at /lib64/libc.so.6
#1  0x00007fffe7b48f10 in http_query_set_host () at /usr/lib64/sane/libsane-airscan.so.1
#2  0x00007fffe7b49a2f in http_query_start_processing () at /usr/lib64/sane/libsane-airscan.so.1
#3  0x00007fffe7b4af8c in eloop_thread_func () at /usr/lib64/sane/libsane-airscan.so.1
#4  0x00007ffff6c70432 in start_thread () at /lib64/libpthread.so.0
#5  0x00007ffff74a1913 in clone () at /lib64/libc.so.6


Version-Release number of selected component (if applicable):

libsane-airscan.so.1

How reproducible:

Always

Steps to Reproduce:
1. Open skanlite, wait a few seconds for connection attempt, crash happens
2. Alternatively, open Gimp, menu File, Create, XSane: device dialog

Actual results:
Both applications crash, making it impossible to use the scanner.

Expected results:
Being able to use the scanner normally.


Additional info:

Comment 1 Zdenek Dohnal 2020-09-29 14:23:49 UTC
Hi,

thank you for reporting the issue!

Would you mind installing sane-airscan-debugsource, libsane-airscan-debuginfo packages and attaching the full backtrace of the crash?

You can get it via 'coredumctl gdb' if the crash is the last crash which happened on the machine.

Then please issue following gdb commands:

(gdb) set logging on

(gdb) set logging file gdb_log

(gdb) bt f

(gdb) q

and attach the gdb_log file as an attachment to this ticket.

Comment 2 thranur 2020-09-29 20:41:45 UTC
Created attachment 1717662 [details]
stack trace (with gdb 'bt f' and debug packages) of segmentation fault in airscan, when running skanlite

Comment 3 thranur 2020-09-29 20:43:54 UTC
Thank you very much for the instructions.

I tried following them, and installed the debugsource and debuginfo packages as mentioned.

Then, I tried re-running skanlite to get a crash. It crashed as before, then I ran `coredumpctl gdb`, but got the following:

           PID: 3505692 (xsane)
           UID: 1000
           GID: 1000
        Signal: 11 (SEGV)
     Timestamp: Thu 2020-09-24 19:27:25 CEST (5 days ago)
  Command Line: xsane
    Executable: /usr/bin/xsane
 Control Group: /user.slice/user-1000.slice/session-1.scope
          Unit: session-1.scope
         Slice: user-1000.slice
       Session: 1
     Owner UID: 1000
       Boot ID: 0a38b9c4738b4e04b7e3e3eaf3291785
    Machine ID: 13e6db43a6d747cd9b7b168d166b6703
      Hostname: host
       Storage: none
       Message: Process 3505692 (xsane) of user 1000 dumped core.

Coredump entry has no core attached (neither internally in the journal nor externally on disk).


So, trying to solve the "has no core attached", I did `ulimit -c unlimited`, but still nothing.

I then decided running `gdb skanlite` to see if I could get something. Upon doing so, I noticed the message:

"Missing separate debuginfos, use: dnf debuginfo-install skanlite-2.1.0.1-4.fc32.x86_64"

So I did install it; it installed the following packages: skanlite-debugsource-2.1.0.1-4.fc32.x86_64.rpm and skanlite-debuginfo-2.1.0.1-4.fc32.x86_64.rpm

Then, I re-ran `gdb skanlite` again and... it didn't crash! I could even see the preview window.

So, I tried running Gimp again, for xsane acquire, but it still crashed. And now re-running skanlite crashes again, but in a slightly different manner. I wonder if the non-determinism might be related to Wifi scans.

Anyway, I am now unable to get a core file generated by running the program; I only get a segmentation fault. I got a stack trace but it has several "<optimized out>" parts, so I'm not sure how useful it is.

I'm attaching it anyway, but if more information is needed, I'm afraid I might need some more guidance about how to force generation of a proper core file.

On a side note, whenever I run gdb, I get a message "Missing separate debuginfos, use: dnf debuginfo-install systemd-libs-245.7-1.fc32.x86_64", but when I try installing this package, I get "Could not find debuginfo package for the following installed packages: systemd-libs-245.7-1.fc32.x86_64". I did install several dozen other debug packages as it suggested.

Comment 4 Zdenek Dohnal 2020-10-01 10:45:12 UTC
(In reply to thranur from comment #3)
> Anyway, I am now unable to get a core file generated by running the program;
> I only get a segmentation fault. I got a stack trace but it has several
> "<optimized out>" parts, so I'm not sure how useful it is.
> 
> I'm attaching it anyway, but if more information is needed, I'm afraid I
> might need some more guidance about how to force generation of a proper core
> file.

You're right, the backtrace doesn't say much this way, sorry :( . That can be caused by some debuginfo package missing or the app has a high level of optimization.

I see the sigsegv from coredumpctl is from xsane, are you able to get sigsegv from xsane every time? You can run it as standalone app - f.e. from CLI:

$ xsane

In gdb, you can run xsane as (with debuginfo/debugsource packages installed):

$ gdb /usr/bin/xsane

and then (if the xsane process crashes):

(gdb) r

, then follow the steps from my previous comment and attach the debug file again.

Thank you for your cooperation!

Comment 5 Zdenek Dohnal 2020-10-01 11:14:05 UTC
I'm going to report the issue upstream, would you mind doing following steps too:

1) change the following lines in /etc/sane.d/airscan.conf:

[debug]
#trace = ~/airscan/trace
#enable = true

->

[debug]
trace = <directory of your choice>
enable = true


2) reproduce the problem

3) There will be .log and .tar files created after reproducing the issue in <directory of your choice>. Please attach those files here too.

Comment 6 Zdenek Dohnal 2020-10-01 11:21:31 UTC
Reported upstream https://github.com/alexpevzner/sane-airscan/issues/77

Comment 7 Zdenek Dohnal 2020-10-01 12:09:13 UTC
One other thing - valgrind output can tell us more too, would you mind executing:

$ valgrind --leak-check=full --log-file=valgrind_log xsane

and attaching valgrind_log as attachment?

Comment 8 thranur 2020-10-01 20:43:16 UTC
Created attachment 1718312 [details]
log generated after enabling trace on /etc/xsane.d/airscan.conf and running xsane

Comment 9 thranur 2020-10-01 20:53:04 UTC
Created attachment 1718313 [details]
log generated by 'valgrind --leak-check=full --log-file=valgrind_log xsane' while connected to wifi

Comment 10 thranur 2020-10-01 20:54:39 UTC
It's possible the issue is caused by the French Internet provider "Bouygues" and the configuration of its "BBox" home router. They seem to provide some sort of network shared printer (as explained by the "bbox ippos printer" mentioned in the trace). which seems to trigger it. If I run xsane without connecting to the WiFi, xsane works normally.

By the way, the .tar file generated by trace was empty, so I didn't include it.

Valgrind did report some 250k of issues.

At least the good thing is that the error happens every time when connected, so it's fairly easy for me to reproduce it.

Please tell me if there are other logs that I can provide.

Comment 11 Zdenek Dohnal 2020-10-02 07:15:05 UTC
Thank you for all the logs! I'll send them upstream and look into them myself.

I'll let you know if we will need more info or when there be a package to test.

Comment 12 Zdenek Dohnal 2020-10-05 13:26:15 UTC
Hi,

upstream came with a possible fix - I backported it and built it as this scratch build for now https://koji.fedoraproject.org/koji/taskinfo?taskID=52804680 .

Would you mind installing the rpms from there (click on BuildArch and then there are rpms at the bottom of the page) and trying if they help?

Comment 13 thranur 2020-10-06 21:14:46 UTC
Thank you very much, it works!

Now I just get the "No devices available" dialog when running xsane, which is normal since the scanner is not wifi-enabled.

If there is some other information I may provide, for future information or something, just tell me.

Otherwise, I believe the bug can be closed. Thanks again!

Comment 14 Fedora Update System 2020-10-07 05:18:18 UTC
FEDORA-2020-a062f775be has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-a062f775be

Comment 15 Fedora Update System 2020-10-07 05:24:49 UTC
FEDORA-2020-7b40dbf255 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-7b40dbf255

Comment 16 Fedora Update System 2020-10-07 14:30:31 UTC
FEDORA-2020-a062f775be has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-a062f775be`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a062f775be

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 17 Fedora Update System 2020-10-07 20:45:06 UTC
FEDORA-2020-7b40dbf255 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-7b40dbf255`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-7b40dbf255

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 18 Fedora Update System 2020-10-09 16:37:53 UTC
FEDORA-2020-0eac89d52b has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-0eac89d52b`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0eac89d52b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 19 Fedora Update System 2020-10-09 18:15:40 UTC
FEDORA-2020-93112ac75a has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-93112ac75a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-93112ac75a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 20 Fedora Update System 2020-10-17 14:08:37 UTC
FEDORA-2020-0eac89d52b has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 21 Yann Soubeyrand 2020-11-07 16:15:51 UTC
Hello,

I'm using Fedora Silverblue 33 which, if I understand correctly, contains the fix:


```
rpm-ostree db list 70cea0b9fa84a8a7aa8b8dd33a7710ae16e632458f9931a60906d043c148f475 | grep airscan
 libsane-airscan-0.99.18-1.fc33.x86_64
 sane-airscan-0.99.18-1.fc33.x86_64
```

However scanimage -L is still segfaulting (as well as simple-scan).

As thranur mentioned, disconnecting from wifi prevents the segfaults (but also prevents me from scanning :-P).

I'm using a Brother MFC-9330CDW multi-function printer.

Regards

Yann

Comment 22 Zdenek Dohnal 2020-11-09 05:42:15 UTC
Hi Yann,

thank you for letting me know!

Please open a new bugzilla ticket and provide a full backtrace of the crash.

The fact the app is crashing with segfault and disconnecting from wifi fixes it as it did in thranur's case doesn't have to mean it crashes in the same part of code, which is supposed to be fixed by this ticket.


Note You need to log in before you can comment on or make changes to this bug.