SUMMARY Both skanlite and skanpage crash on boot when connecting to a saned-based network scanner. Xsane is able to connect fine. The stacktrace is: ``` Thread 1 "skanlite" received signal SIGSEGV, Segmentation fault. __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76 Downloading 0.01 MB source file /usr/src/debug/glibc-2.37/string/../sysdeps/x86_64/multiarch/strlen-avx2.S 76 VPCMPEQ (%rdi), %ymm0, %ymm1 Missing separate debuginfos, use: zypper install skanlite-debuginfo-22.12.3-1.2.x86_64 (gdb) bt #0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76 #1 0x00007fffcc0fb42a in do_authorization (dev=0x5555555af800, resource=0x58 <error: Cannot access memory at address 0x58>) at /usr/src/debug/sane-backends-1.1.1/backend/net.c:650 #2 0x00007fffcc0fe2ad in sane_net_control_option (handle=0x555555bae6e0, option=2, action=<optimized out>, value=0x7fffffffcd80, info=0x7fffffffcd24) at /usr/src/debug/sane-backends-1.1.1/backend/net.c:1792 #3 0x00007ffff7753b87 in KSaneCore::ListOption::readValue (this=0x555555a5a3a0) at /usr/src/debug/ksanecore-22.12.3/src/options/listoption.cpp:33 #4 0x00007ffff77588f8 in KSaneCore::InterfacePrivate::loadDeviceOptions (this=<optimized out>) at /usr/src/debug/ksanecore-22.12.3/src/interface_p.cpp:151 #5 0x00007ffff7f7966f in KSaneIface::KSaneWidget::openDevice (this=0x555555901330, deviceName=...) at /usr/src/debug/libksane-22.12.3/src/ksanewidget.cpp:293 #6 0x00005555555655fb in Skanlite::Skanlite (parent=0x0, device=..., this=0x7fffffffd500) at /usr/src/debug/skanlite-22.12.3/src/skanlite.cpp:198 #7 main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/skanlite-22.12.3/src/main.cpp:84 ``` This warning appeared immediately before the crash: ``` [13:18:01.754776] [sanei_wire] sanei_w_array: DECODE: maximum amount of allocated memory exceeded (limit: 1048576, new allocation: 7008781732, total: 7009830308 bytes) ``` More details from the crash in sane-backends, where reply.resource_to_authorise is 0x58 for some reason: ``` #2 0x00007fffcc0fe2ad in sane_net_control_option (handle=0x555555bae6e0, option=2, action=<optimized out>, value=0x7fffffffcd80, info=0x7fffffffcd24) at /usr/src/debug/sane-backends-1.1.1/backend/net.c:1792 1792 do_authorization (s->hw, reply.resource_to_authorize); (gdb) list 1787 status = reply.status; 1788 need_auth = (reply.resource_to_authorize != 0); 1789 if (need_auth) 1790 { 1791 DBG (3, "sane_control_option: auth required\n"); 1792 do_authorization (s->hw, reply.resource_to_authorize); 1793 sanei_w_free (&s->hw->wire, 1794 (WireCodecFunc) sanei_w_control_option_reply, &reply); 1795 1796 sanei_w_set_dir (&s->hw->wire, WIRE_DECODE); (gdb) print reply $1 = {status = SANE_STATUS_GOOD, info = 2, value_type = 0, value_size = 57, value = 0x7fffffffce50, resource_to_authorize = 0x58 <error: Cannot access memory at address 0x58>} (gdb) q ``` STEPS TO REPRODUCE 1. Configure the 'net' sane backend. (Uncomment 'net' from /etc/saned.d/dll.conf, and add the hostname of the saned server to /etc/saned.d/net.conf) 2. Make sure there is a saned server running. (I'm using Debian armhf 'sane-utils' version 1.0.31-4.1) 3. OBSERVED RESULT The crash above when either skanpage or skanlite starts. EXPECTED RESULT Like non-ksanecore-based scanning programs, they work without crashing. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230330 KDE Plasma Version: 5.27.3 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.8-1-vanilla (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i7-7560U CPU @ 2.40GHz Memory: 15.3 Gio of RAM Graphics Processor: Mesa Intel® Iris® Plus Graphics 640 Manufacturer: Dell Inc. Product Name: XPS 13 9360 ADDITIONAL INFORMATION This looks like it's probably a sane-backends or saned issue, but clearly KSaneCore is doing something to trigger it that Xsane isn't.
Created attachment 158750 [details] backtrace of skanlite crash I get the same symptoms if a state file from a previous launch of skanlite or skanpage is present: STEPS TO REPRODUCE (using skanlite as the example, same happens with skanpage) 1. rm -rf ~/.local/share/skanlite 2. skanlite (runs OK) 3. quit skanlite 4. skanlite (Crashes see OBSERVED RESULT) OBSERVED RESULT 22 -- exe=/usr/bin/skanlite 17 -- platform=wayland 17 -- appname=skanlite 17 -- apppath=/usr/bin 10 -- signal=11 9 -- pid=1894 19 -- appversion=23.04.0 21 -- programname=Skanlite 31 -- [email protected] KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = skanlite path = /usr/bin pid = 1894 KCrash: Arguments: /usr/bin/skanlite KCrash: Attempting to start /usr/lib/drkonqi The Wayland connection experienced a fatal error: Transport endpoint is not connected org.kde.drkonqi: The specified process does not exist. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Kernel Version: 6.3.1-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 2 × AMD A6-6400K APU with Radeon(tm) HD Graphics Memory: 7.7 GiB of RAM Graphics Processor: AMD CEDAR ADDITIONAL INFORMATION * No skanlite process remains in the process list after step 3 (so different from bug #334773) * scanimage works every time * On a laptop running KDE Neon User Edition on the same network, skanlite works every time * The debug output from saned is: saned[2871]: handle_client: spawning child process saned[3179]: handle_connection: processing client connection saned[3179]: check_host: access by remote host: fe80::feaa:14ff:fe8e:fa2b%eth0 saned[3179]: check_host: remote host is not IN_LOOPBACK nor IN6_LOOPBACK saned[3179]: check_host: local hostname: b3 saned[3179]: check_host: local hostname(s) (from DNS): b3 saned[3179]: check_host: local hostname(s) (from DNS): (null) saned[3179]: check_host: local hostname(s) (from DNS): (null) saned[3179]: check_host: remote host doesn't have same addr as local saned[3179]: check_host: opening config file: /etc/hosts.equiv saned[3179]: check_host: can't open config file: /etc/hosts.equiv (No such file or directory) saned[3179]: check_host: opening config file: saned.conf saned[3179]: check_host: config file line: `192.168.0.0/24' saned[3179]: check_host: subnet with base IP = 192.168.0.0, CIDR netmask = 24 saned[3179]: check_host: config file line: `[fe80::]/64' saned[3179]: check_host: subnet with base IP = [fe80::], CIDR netmask = 64 saned[3179]: check_host: access granted from IP address fe80::feaa:14ff:fe8e:fa2b%eth0 (in subnet [fe80::]/64) saned[3179]: init: access granted saned[3179]: init: access granted to paul@fe80::feaa:14ff:fe8e:fa2b%eth0 saned[3179]: process_request: waiting for request saned[3179]: process_request: got request 2 saned[3179]: process_request: access to resource `epson2' granted saned[3179]: process_request: sane_open returned: Success saned[3179]: process_request: waiting for request saned[3179]: process_request: got request 4 saned[3179]: process_request: waiting for request saned[3179]: process_request: got request 5 saned[3179]: process_request: waiting for request saned[3179]: process_request: got request 1 saned[3179]: io/hpmud/model.c 534: no hp_Deskjet_D2300_series attributes found in /usr/share/hplip/data/models/models.dat saned[3179]: io/hpmud/model.c 545: no hp_Deskjet_D2300_series attributes found in /usr/share/hplip/data/models/unreleased/unreleased.dat saned[3179]: process_request: waiting for request saned[3179]: process_request: bad status 22 saned[3179]: quit: exiting * running skanlite in gdb gives the attached backtrace
Thanks — I can confirm that deleting the state file (or even just removing the 'deviceName' entry in it) fixes the issue here as well (at least until the next time I start the program).
If I turn the scanner off and on so that it's name changes, e.g. from net:b3.local:epson2:libusb:001:011 to net:b3.local:epson2:libusb:001:012 then the next attempt to launch skanlite works OK
I can still reproduce this bug on openSUSE Leap 15.5 and openSUSE Tumbleweed 20231203. However, I can't reproduce it on Fedora 39.
Looks like a duplicate of https://bugs.kde.org/show_bug.cgi?id=444987
Git commit ee34096fefa78887d102fa65f2492aa4cb215f37 by Andras Mantia, on behalf of Andras Mantia. Committed on 30/05/2024 at 12:25. Pushed by amantia into branch 'master'. Don't crash scanner apps (skanlite, skanpage) when searching for scanners This is triggered eg. with network scanners where scanning takes longer time. As comment says: this defeats the idea of using a scanner thread, but the proper fix would be more elaborate (ie. do the rest of initialization only when the thread is finished). Still makes sense to have this hotfix, especially as this is an old bug... Related: bug 444987 M +7 -0 src/interface_p.cpp https://invent.kde.org/libraries/ksanecore/-/commit/ee34096fefa78887d102fa65f2492aa4cb215f37