[sane-devel] DLL backend doesn't work on 680x0 machines

Dave Huang khym@azeotrope.org
Sat, 12 Apr 2003 23:39:13 -0500


On Sat, Apr 12, 2003 at 08:09:22PM -0500, Dave Huang wrote:
> used the net backend. That all worked fine, but scanimage -h from a 
> remote machine causes saned on the m68k machine to crash trying to 
> write to a null pointer when scanimage gets the list of options... 
> here's the end of the log from saned with SANE_DEBUG_DLL set to 4:
> 
> [dll] sane_control_option(handle=0x101e0,option=15,action=0,value=0x10180,info=0xffffc8dc)
> [dll] sane_control_option(handle=0x101e0,option=18,action=0,value=0x10180,info=0xffffc8dc)
> [dll] sane_control_option(handle=0x101e0,option=19,action=0,value=0x0,info=0xffffc8dc)
> 
> note that value is 0x0... it's correct for all the previous calls to
> sane_control_option, so I don't know why it's different for option=19.
> Also, I don't know if this is caused by my patch, or if this is a
> completely unrelated problem.

I think this is unrelated, since the function parameters are being
passed correctly from the dll backend to the real hardware driver
backend (hp, in my case). The problem is that the dll backend is being
called with a null pointer. Perhaps someone who understands the net
backend and/or the wire protocol stuff will know what's going on...

w_option_value() is being called, with type = SANE_TYPE_BUTTON, so
w_value = (WireCodecFunc) sanei_w_void; len = 0; element_size = 0;
Then in sanei_w_array(), if len == 0, the value is set to 0. That 0 is
passed along until it eventually gets to hp_accessor_bool_get as the
valp pointer, which then does:
  *(SANE_Bool*)valp = val ? SANE_TRUE : SANE_FALSE;
Dereference of NULL valp causes a segmentation fault.

Here's a stack trace... and no, I don't know why gdb thinks some of 
these functions are in /usr/include/stdio.h :)

#0  0x810f86a in hp_accessor_bool_get (this=0xed68, data=0x20148, valp=0x0)
    at hp-accessor.c:901
#1  0x810f548 in sanei_hp_accessor_get (this=0xed68, data=0x20148, valp=0x0)
    at hp-accessor.c:901
#2  0x8113812 in hp_option_get (this=0xed08, data=0x20148, valp=0x0)
    at /usr/include/stdio.h:428
#3  0x8113f2e in hp_option_imm_control (optset=0x1e008, this=0xed08,
    data=0x20148, action=SANE_ACTION_GET_VALUE, valp=0x0, infop=0xffffc8b4,
    scsi=0x16008) at /usr/include/stdio.h:428
#4  0x8119798 in sanei_hp_optset_control (this=0x1e008, data=0x20148,
    optnum=19, action=SANE_ACTION_GET_VALUE, valp=0x0, infop=0xffffc8b4,
    scsi=0x16008, immediate=1) at /usr/include/stdio.h:428
#5  0x811214a in sanei_hp_handle_control (this=0x14788, optnum=19,
    action=SANE_ACTION_GET_VALUE, valp=0x0, info=0xffffc8b4) at hp-handle.c:697
#6  0x810cca4 in sane_hp_control_option (handle=0x14788, optnum=19,
    action=SANE_ACTION_GET_VALUE, valp=0x0, info=0xffffc8b4) at hp.c:972
#7  0x80256fc in sane_dll_control_option (handle=0x111e0, option=19,
    action=SANE_ACTION_GET_VALUE, value=0x0, info=0xffffc8b4) at dll.c:1052
#8  0x8025a08 in sane_control_option (h=0x111e0, opt=19,
    act=SANE_ACTION_GET_VALUE, val=0x0, info=0xffffc8b4) at dll-s.c:83
#9  0x5c5a in process_request (w=0xdbe0) at saned.c:1040
#10 0x64f4 in main (argc=2, argv=0xffffc998) at saned.c:1310
#11 0x3b88 in __start ()