Threading issue caused by multiple invocations leading to a crash below scanner_do_redetect.
I received a coredump from simple-scan and found it similar to one report here.
My core from a Buster/testing with packages from around 2019-02-07 leads to this backtrace:
Thread 1 (Thread 0x7f7185579700 (LWP 1366)): #0 sane_reload_devices () at avision.c:7711 #1 0x00007f717bfc603f in sane_avision_get_devices (device_list=0x7f71855789a0, local_only=<optimized out>) at avision.c:7787 #2 0x00007f719d446cd0 in sane_dll_get_devices (device_list=device_list@entry=0x7f7185578a18, local_only=local_only@entry=0) at dll.c:1081 #3 0x00007f719d42fdb5 in sane_get_devices (dl=dl@entry=0x7f7185578a18, local=local@entry=0) at dll-s.c:17 #4 0x000055d995e55a21 in scanner_do_redetect (self=0x55d997ac6ed0) at ../src/scanner.vala:340 #5 0x000055d995e57188 in scanner_scan_thread (self=<optimized out>) at ../src/scanner.vala:1487 #6 _scanner_scan_thread_gthread_func (self=<optimized out>) at scanner.c:12763 #7 0x00007f719e293325 in g_thread_proxy (data=0x55d997b2d8a0) at ../../../glib/gthread.c:784 #8 0x00007f719ccaffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486 #9 0x00007f719ce367ef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
7711 if (attaching_hw->usb_vendor != 0 && attaching_hw->usb_product != 0 )
(gdb) print attaching_hw $1 = (Avision_HWEntry *) 0x7f717bfdb040 <Avision_Device_List> (gdb) print attaching_hw->usb_vendor $2 = 0 (gdb) print attaching_hw->usb_product $3 = 0 (gdb) display/i $pc 1: x/i $pc => 0x7f717bfbc07a <sane_reload_devices+970>: mov 0x10(%rax),%edx (gdb) print/x $rax $4 = 0x0
While in this core the variables show kind of sane values, the current register contains a value leading to a segfault.
Therefore I supsected a threading issue and really found variable
attaching_hw having static storage and another thread currently running inside sane_reload_devices, that may have set the variable at an inappropriate time:
Thread 2 (Thread 0x7f716a7fc700 (LWP 2043)): #0 __GI___libc_read (nbytes=4096, buf=0x7f715c002a70, fd=191) at ../sysdeps/unix/sysv/linux/read.c:26 #1 __GI___libc_read (fd=191, buf=0x7f715c002a70, nbytes=4096) at ../sysdeps/unix/sysv/linux/read.c:24 #2 0x00007f719cdb98c8 in _IO_new_file_underflow (fp=0x7f715c001460) at libioP.h:839 #3 0x00007f719cdb8948 in __GI__IO_file_xsgetn (fp=0x7f715c001460, data=<optimized out>, n=32) at fileops.c:1329 #4 0x00007f719cdad887 in __GI__IO_fread (buf=buf@entry=0x7f716a7f9601, size=size@entry=1, count=count@entry=32, fp=fp@entry=0x7f715c001460) at iofread.c:38 #5 0x00007f719d436728 in fread (__stream=0x7f715c001460, __n=32, __size=1, __ptr=0x7f716a7f9601) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:294 #6 sanei_scsi_find_devices (findvendor=0x7f717bfcf1d1 "AVISION", findmodel=0x7f717bfd0683 "AV100CS", findtype=findtype@entry=0x0, findbus=findbus@entry=-1, findchannel=findchannel@entry=-1, findid=findid@entry=-1, findlun=-1, attach=0x7f717bfc0570 <attach_one_scsi>) at sanei_scsi.c:3083 #7 0x00007f717bfbc071 in sane_reload_devices () at avision.c:7706 #8 0x00007f717bfc603f in sane_avision_get_devices (device_list=0x7f716a7fb9a0, local_only=<optimized out>) at avision.c:7787 #9 0x00007f719d446cd0 in sane_dll_get_devices (device_list=device_list@entry=0x7f716a7fba18, local_only=local_only@entry=0) at dll.c:1081 #10 0x00007f719d42fdb5 in sane_get_devices (dl=dl@entry=0x7f716a7fba18, local=local@entry=0) at dll-s.c:17 #11 0x000055d995e55a21 in scanner_do_redetect (self=0x55d997ac6ed0) at ../src/scanner.vala:340 #12 0x000055d995e57188 in scanner_scan_thread (self=<optimized out>) at ../src/scanner.vala:1487 #13 _scanner_scan_thread_gthread_func (self=<optimized out>) at scanner.c:12763 #14 0x00007f719e293325 in g_thread_proxy (data=0x55d997caaf20) at ../../../glib/gthread.c:784 #15 0x00007f719ccaffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486 #16 0x00007f719ce367ef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
I tested multiple invocations of simple-scan in short order and found it crash on different places, all in similar stacks upon
sane_reload_devices, each time in functions specific for different scanners.
This documentation shows this
GtkApplication defaults to applications being single-instance. If the user attempts to start a second instance of a single-instance application then GtkApplication will signal the first instance and you will receive additional activate or open signals. In this case, the second instance will exit immediately, without calling startup or shutdown.
Therefore I am not sure, but assume
sane_get_devices is not meant to be thread safe, therefore multiple accesses should be protected somehow or just one instance of
scanner_scan_thread be allowed.
Could you reproduce any crash when starting multiple instances in short order?