Hi,
Thanks you for your report.
Unfortunately, I don't think we have a maintainer for the canon backend
at the moment.
I suspect that few people have the capability these days to test
canon/TPU combinations of this sort which is probably why you are the
only one to encounter this in recent times.
I will try to have a look at the code sometime but I am not familiar
with that backend.
Cheers,
Ralph
On 2023-06-25 05:46, Alain Zscheile via sane-devel wrote:
Hi,
while trying to use a scanner I encountered a segfault
in simple-scan, which turned out to be caused by the sane-canon
backend driver.
backtrace|:||#0 __strlen_sse2 () at
../sysdeps/x86_64/multiarch/strlen-sse2.S:142||||#1 0x00007fe7c722cb02
in __GI___strdup (s=0x0) at strdup.c:41||||#2 0x00007fe7a5ca4e57 in
init_options (s=s@entry=0x7fe7a01c64d0) at canon.c:1764 #3
0x00007fe7a5ca8be1 in sane_canon_open (devnam=<optimized out>,
handle=0x7fe7b4ffea48) at
/build/sane-backends-1.2.1/backend/canon-sane.c:205 #4
0x00007fe7c7458ff4 in sane_dll_open (full_name=<optimized out>,
meta_handle=meta_handle@entry=0x7fe7b4ffeab0) at dll.c:1294 #5
0x00007fe7c745599e in sane_open (name=<optimized out>,
h=h@entry=0x7fe7b4ffeab0) at dll-s.c:27 #6 0x000000000043c897 in
scanner_do_open (self=self@entry=0x1485850) at
src/simple-scan.p/scanner.c:5419 #7 0x000000000043e0ee in
scanner_scan_thread (self=self@entry=0x1485850) at
src/simple-scan.p/scanner.c:7320 #8 0x000000000043e12b in
_scanner_scan_thread_gthread_func (self=0x1485850) at
src/simple-scan.p/scanner.c:7355 #9 0x00007fe7c82ab64d in
g_thread_proxy () from
/nix/store/cgmbz0wglid7v5m0m0a70ksvgyxppsgn-glib-2.76.3/lib/libglib-2.0.so.0
#10 0x00007fe7c7216dd4 in start_thread (arg=<optimized out>) at
pthread_create.c:444 #11 0x00007fe7c72989b0 in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81|
In
https://gitlab.com/sane-project/backends/-/blob/1.2.1/backend/canon.c#L1764
<https://gitlab.com/sane-project/backends/-/blob/1.2.1/backend/canon.c#L1764>when|s->hw->tpu.ControlMode
is set to 3, `strdup(0)` is called, which|
|leads to the segfault.|
By now, I applied the following patch,
in accordance with
https://gitlab.com/sane-project/backends/-/blob/1.2.1/backend/canon-sane.c#L676
<snip>
diff --git a/backend/canon.c b/backend/canon.c
index d17cd01a4..6a0b8aa07 100644
--- a/backend/canon.c
+++ b/backend/canon.c
@@ -166,6 +166,7 @@ static const SANE_String_Const mode_list_fb1200[] = {
static const SANE_String_Const tpu_dc_mode_list[] = {
SANE_I18N("No transparency correction"),
SANE_I18N("Correction according to film type"),
+ SANE_I18N("Correction according to ??? (unhandled)"),
SANE_I18N("Correction according to transparency ratio"),
0
};
</snip>
but I don't really know what a proper solution would be...
ControlMode = 2 doesn't seem to be handled anywhere
(in contrast to ControlMode = 0,1,3).
This also doesn't seem to be introduced recently, as the related code
appears to be introduced some 23 years ago, and was last modified 16
years
ago to introduce SANE_I18N...
downstream report: https://github.com/NixOS/nixpkgs/issues/239726
Regards,
Alain Fogtia Zscheile
