Hi, the bug in the hp-backend has been fixed in CVS. Here is the relevant patch to hp-option.c for those who don't like CVS (you may need to apply the changes manually due to lines which have been splitted):
--- hp-option.c.orig Mon Nov 25 21:36:35 2002 +++ hp-option.c Mon Apr 14 21:24:21 2003 @@ -3910,7 +3910,7 @@ hp_bool_t immediate) { HpOption opt = hp_optset_getByIndex(this, optnum); - SANE_Int my_info = 0; + SANE_Int my_info = 0, my_val = 0; DBG(3,"sanei_hp_optset_control: %s\n", opt ? opt->descriptor->name : ""); @@ -3922,6 +3922,23 @@ if (!opt) return SANE_STATUS_INVAL; + /* There are problems with SANE_ACTION_GET_VALUE and valp == 0. */ + /* Check if we really need valp. */ + if ((action == SANE_ACTION_GET_VALUE) && (!valp)) + { + /* Options without a value ? */ + if ( (opt->descriptor->type == SANE_TYPE_BUTTON) + || (opt->descriptor->type == SANE_TYPE_GROUP)) + { + valp = &my_val; /* Just simulate a return value locally. */ + } + else /* Others must return a value. So this is invalid */ + { + DBG(1, "sanei_hp_optset_control: get value, but valp == 0\n"); + return SANE_STATUS_INVAL; + } + } + if (immediate) RETURN_IF_FAIL( hp_option_imm_control(this, opt, data, action, valp, infop, scsi) ); 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