[sane-devel] hp backend bug? (was: DLL backend doesn't work on 680x0 machines)

[Henning Meier-Geinitz]

Hi,

I have adjsuted the subject.

On Sat, Apr 12, 2003 at 11:39:13PM -0500, Dave Huang wrote:
> 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).

I think so, too.

> The problem is that the dll backend is being called with a null
> pointer.

That's correct, by the way. SANE standard 4.2.9.4 says "SANE_TYPE_BUTTON
An option of this type has no value."

> 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

I think this is correct.

> until it eventually gets to hp_accessor_bool_get as the

But a button can't be read. You can only set a button. A
SANE_TYPE_BUTTON is an event that comes from the frontend. So the
backend should return with an error code and not try to read a value
at all. A SANE_TYPE_BUTTON is not a boolean value.

Maybe the frontend shouldn't even ask for the value, but the backend
must cope with this anyway.

> valp pointer, which then does:
>   *(SANE_Bool*)valp = val ? SANE_TRUE : SANE_FALSE;
> Dereference of NULL valp causes a segmentation fault.

I guess the same happens without net, but then the pointer may point
to something useful by luck.

I'll let the hp maintainer find out, the hp backend has to many files
and levels for me to understand :-)

Bye,
  Henning