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
