[sane-devel] Trouble with sanei_usb change (commit ef5820ce6238469b9946b37e21ec5355edfa520a)

[Stef]

On 28/02/2013 08:14, Gerhard Jäger wrote:
> Hi Stef,
>
> On Thursday 28 February 2013 07:28:55 Stef wrote:
>> On 27/02/2013 22:10, Stef wrote:
>>> On 27/02/2013 21:59, Stef wrote:
>>>> Hello,
>>>>
>>>>      the ef5820ce6238469b9946b37e21ec5355edfa520a commit is causing me
>>>> troubles.
>>>> Should we free devname on close ? We can open/close several times the
>>>> same device, so I think freeing in sanei_usb_close is problematic.
>>>> Reverting this change restored functionality to my backend.
>
> sorry for that - I think I was too fast and remember that ages ago this
> was the reason, why we didn't free devname...
> [...]
>>       regarding the memory leak, the following patch takes care of the
>> case where memory is leaked on device that get unplugged or powered off.
>>        About the few bytes left when a backend exits, what is really
>> needed is a sanei_usb_exit function. This function would free allocated
>> resources when the last user of sanei_usb_init() calls it.
> [...]
>
> okay - I'd say, apply the patch and if possible make a proposal for
> sanei_usb_exit() or _cleanup().
>
> TIA
>   Gerhard
>
     Hello,

     I have applied the patch to sanei_usb.c .
     Since actual device scanning takes place in sanei_usb_init, some 
backends call it each time sane_get_device is called. So counting the 
number of user of the resources can't currently be done, and we cannot 
free resources until last user leave. When backends are loaded by the 
same frontend (such as saned) we cannot currently find if it safe to 
free resources.
     So be able to free the few lost bytes we have to:
     - move the usb device scanning logic out of sanei_usb_init() and 
publish it as sanei_usb_rescan()
     - make sure all backends use sanei_usb_init() only once
     - make sure backends use sanei_usb_rescan()
     - create a sanei_usb_exit() that free allocated resources
     - make sure all backends use sanei_usb_exit()

     This is quite some work for an handful of leaked bytes and need 
serious testing (even a test suite with mock device).

Regards,
     Stef