[sane-devel] [dev] net backend and timing problems? (pretty weird)

[mh]

Henning Meier-Geinitz, Don, 06 Sep 2001:
> Can you provide some more lines of backtrace so we can see what
> sane-net is trying to achieve here? What's in line 345? Is this a
> modified sanei_wire.c? I'm asking because flush() starts in line  390
> in the code I have. Also I don't understand #2 -> #1 -> #0 , because I
> don't see where write () would be involved in flush ().

Hi,
here's another bt. I think, however, that the line numbers are complete
nonsense. Maybe that's related to the gdb version (4.18) shipping with SuSE
7.0. I'm using the original sanei_wire.c from SANE 1.0.5 .

Program received signal
SIGPIPE, Broken pipe. 0x403f7004 in write () from /lib/libc.so.6
(gdb) bt
#0  0x403f7004 in write () from /lib/libc.so.6
#1  0x404a6408 in __DTOR_END__ () from /usr/local/lib/sane/libsane-net.so.1
#2  0x404a45ca in flush (w=0x810e134) at sanei_wire.c:345
#3  0x404a4614 in sanei_w_set_dir () at sanei_wire.c:345
#4  0x404a468b in sanei_w_call () at sanei_wire.c:345
#5  0x404a25b2 in sane_net_control_option () at net.c:291
#6  0x4001799b in sane_dll_control_option () from /usr/local/lib/libsane.so.1
#7  0x40017c71 in sane_control_option () from /usr/local/lib/libsane.so.1
#8  0x8054925 in xsane_control_option (handle=0x8115820, option=7,
    action=SANE_ACTION_SET_VALUE, val=0x8152320, info=0x0)
    at xsane-back-gtk.c:175
#9  0x8062b0e in preview_restore_option (p=0x8152260, option=7,
    saved_value=0x8152320, valid=1) at xsane-preview.c:1294
#10 0x8063d35 in preview_scan_done (p=0x8152260, save_image=1)
    at xsane-preview.c:1788
#11 0x80631b1 in preview_read_image_data (data=0x8152260, source=9,
    cond=GDK_INPUT_READ) at xsane-preview.c:1482
#12 0x401bd644 in gdk_io_invoke (source=0x816a660, condition=G_IO_IN,
    data=0x815d280) at gdkevents.c:882
#13 0x401ef370 in g_io_unix_dispatch (source_data=0x816a9b8,
    current_time=0xbffff694, user_data=0x815d280) at giounix.c:135
#14 0x401f0c06 in g_main_dispatch (dispatch_time=0xbffff694) at gmain.c:656
#15 0x401f1233 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#16 0x401f13fc in g_main_run () at gmain.c:884
#17 0x4010b30c in gtk_main () at gtkmain.c:807
#18 0x809dab0 in xsane_interface (argc=1, argv=0xbffff8c4) at xsane.c:7607
#19 0x809e021 in main (argc=1, argv=0xbffff8c4) at xsane.c:7765 

[...]
> Just a quick guess: Some sort of race between the final sane_cancel
> and sane_read which leads to closing the data connection before
> sane_read has finished? I don't know if something like that is possible.
> Does this also happen if you use saned in debug mode and are there any
> errors/warnings from saned or the plustek backend (with
> SANE_DEBUG_PLUSTEK=255)?

I tried this before I wrote the mail but couldn't see anything suspicious.
My first attempt to track this down was to add some additional debug lines to
net.c. This revealed, that the problem occurred in (~line 811, net.c)
(that means in this case, that the frontend tries to set an option after the
preview scan has finished)

sanei_w_call (&s->hw->wire, SANE_NET_CONTROL_OPTION,
             (WireCodecFunc) sanei_w_control_option_req, &req,
	     (WireCodecFunc) sanei_w_control_option_reply, &reply);

Therefore I tried to add some printfs to sanei_wire.c . Now things became even
stranger; I didn't get a SIGPIPE any more, but now xsane showed an error
message, stating that sane returned an unknown error number. Since I had about
the same thoughts like you, I tried to add some kind of "delay" (->sleep(3)),
and suddently it worked.
I'm sorry, that I can't provide you with more information, but I don't know
much about the net backend and saned :-( I don't even know, whether it's a
problem in the net backend, saned or the plustek backend. 
I was just hoping that this might be a hint for someone familiar with the net
backend/saned. If there are other things I should try, please let me know.

Bye,
Michael