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

Peter Kirchgessner peter@kirchgessner.net
Mon, 14 Apr 2003 21:40:54 +0200


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-devel@www.mostang.com
> http://www.mostang.com/mailman/listinfo/sane-devel
> 


-- 
Peter Kirchgessner
http://www.kirchgessner.net
mailto:peter@kirchgessner.net