Hi, I will pick it up and look for it.
Sincerely Peter Henning Meier-Geinitz schrieb: > 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 > _______________________________________________ > Sane-devel mailing list > sane-de...@www.mostang.com > http://www.mostang.com/mailman/listinfo/sane-devel > -- Peter Kirchgessner http://www.kirchgessner.net mailto:pe...@kirchgessner.net
