Henning Meier-Geinitz <[EMAIL PROTECTED]> wrote:

Hi Henning,

> At least on first sight it looks like stack corruption for me. I would

Same here. There's something fishy that needs to be ironed out :)

> Running saned -d may lead to different behaviour because the original
> error may not happen (e.g. because saned -d runs as root while from
> (x)inetd its ran as user "saned" or "scanner" or whatever).

Indeed; there's room for improvement in saned/net protocol :)

> server (for whatever reason) and tries to free the device list. #8
> tries to free one of the strings e.g. sane_device.name. Now
> *w->codec.w_string should be called (sanei_wire.c, 350). However this
> happens instead:
>
> #5  0x40746d61 in free () from /lib/libc.so.6
> #6  0x4115f0bd in sanei_w_array () from /usr/lib/sane/libsane-net.so.1
> #7  0x4115e5f2 in sanei_config_read () from /usr/lib/sane/libsane-net.so.1
>
> Either gdb is confused somehow, or sanei_config_read is called
> mistakenly (or I miss something).

Looks like the stack is in a weird state and gdb doesn't detect it.

> I remember similar problems when the sanei_net/sanei_codec* code

Hmm, last time it only produced a deadlock between the client and the
server (both reading at the same time, waiting for data from the other
side).

> between xscanimage and sane-backends ran out of sync. However xsane
> doesn't seem to use sanei at all.

Well, it doesn't have to use it anyway. I'm still unsure as to why
does scanimage use sanei :)

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to