Run xsane with only a hostname in net.conf to access remotely the
scanner.
Press scan. It ask for user/password (?), I just click ok or cancel, and a couple
of seconds later it happens:

(gdb) bt full
#0  0x00007f23f312ea43 in free () from /lib/libc.so.6
No symbol table info available.
#1  0x00007f23e63e89ec in sanei_w_array (w=0x23a96b8, len_ptr=0x7fffff3c4364, v=0x7fffff3c4410, w_element=0x7f23e63e7710 <bin_w_byte>, element_size=1) at sanei_wire.c:181
        len = <value optimized out>
        val = 0x7f23f6fa7baa ""
        i = 2
#2  0x00007f23e63e7618 in bin_w_string (w=0x23a96b8, v=0x7fffff3c4410) at sanei_codec_bin.c:87
        len = 2
#3  0x00007f23e63e7d53 in sanei_w_string (w=0x23a96b8, v=0x7fffff3c4410) at sanei_wire.c:350
No locals.
#4  0x00007f23e63e7ccb in sanei_w_free (w=0x23a96b8, w_reply=0x7f23e63e77d0 <sanei_w_start_reply>, reply=0x7fffff3c4400) at sanei_wire.c:647
        saved_dir = WIRE_DECODE
#5  0x00007f23e63e42ca in sane_net_start (handle=<value optimized out>) at net.c:1942
        s = (Net_Scanner *) 0x2310240
        reply = {status = 1886547811, port = 1702064928, byte_order = 842085168, resource_to_authorize = 0x7f23f6fa7ba8 "�"}
        sin = {sin_family = 2, sin_port = 42521, sin_addr = {s_addr =
117614784},
  sin_zero = "\000\000\000\000\000\000\000"}
        sa = (struct sockaddr *) 0x7fffff3c4420
        sin6 = {sin6_family = 28672, sin6_port = 63226, sin6_flowinfo = 32547, sin6_addr = {in6_u = { u6_addr8 = "��\033�\177\000\000\005\000\000\000\000\000\000", u6_addr16 = {41402, 63259, 32547, 0, 5, 0, 0, 0}, u6_addr32 = {4145783226, 32547, 5, 0}}}, sin6_scope_id = 0}
        status = 1886547811
        fd = 23
        len = 16
        port = <value optimized out>
#6  0x000000000046234c in ?? ()
No symbol table info available.
#7  0x00000000004645eb in ?? ()
No symbol table info available.
#8  0x00007f23f45d2ebd in g_closure_invoke () from
/usr/lib/libgobject-2.0.so.0
No symbol table info available.
#9  0x00007f23f45e5c2d in ?? () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#10 0x00007f23f45e7116 in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
No symbol table info available.
#11 0x00007f23f45e7623 in g_signal_emit () from
/usr/lib/libgobject-2.0.so.0
No symbol table info available.
#12 0x00007f23f58add9d in gtk_real_button_released
(button=0x7f23f6fa7ba8)
    at /scratch/build-area/gtk+2.0-2.12.11/gtk/gtkbutton.c:1484
No locals.
#13 0x00007f23f45d2ebd in g_closure_invoke () from
/usr/lib/libgobject-2.0.so.0
No symbol table info available.
#14 0x00007f23f45e5538 in ?? () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#15 0x00007f23f45e7116 in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
No symbol table info available.
#16 0x00007f23f45e7623 in g_signal_emit () from
/usr/lib/libgobject-2.0.so.0
No symbol table info available.
#17 0x00007f23f58acf3d in gtk_button_button_release
(widget=0x7f23f6fa7ba8, event=0x0)
    at /scratch/build-area/gtk+2.0-2.12.11/gtk/gtkbutton.c:1377
No locals.
#18 0x00007f23f597b688 in _gtk_marshal_BOOLEAN__BOXED
(closure=0x22d7530, return_value=0x7fffff3c66e0,
    n_param_values=<value optimized out>, param_values=0x7fffff3c67a0,
    invocation_hint=<value optimized out>, marshal_data=0x7f23f58acf20)
    at /scratch/build-area/gtk+2.0-2.12.11/gtk/gtkmarshalers.c:84
        data1 = (gpointer) 0x23e5b80
        data2 = (gpointer) 0x7f23f4000000
        v_return = <value optimized out>
        __PRETTY_FUNCTION__ = "_gtk_marshal_BOOLEAN__BOXED"
#19 0x00007f23f45d2ebd in g_closure_invoke () from
/usr/lib/libgobject-2.0.so.0
No symbol table info available.
#20 0x00007f23f45e58fc in ?? () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#21 0x00007f23f45e6f99 in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
No symbol table info available.
#22 0x00007f23f45e7623 in g_signal_emit () from
/usr/lib/libgobject-2.0.so.0
No symbol table info available.
#23 0x00007f23f5a9019e in gtk_widget_event_internal (widget=0x23e5b80,
event=0x25b94b0)
    at /scratch/build-area/gtk+2.0-2.12.11/gtk/gtkwidget.c:4678
        signal_num = <value optimized out>
        return_val = 0
#24 0x00007f23f5974203 in IA__gtk_propagate_event (widget=0x23e5b80,
event=0x25b94b0)
    at /scratch/build-area/gtk+2.0-2.12.11/gtk/gtkmain.c:2336
        tmp = (GtkWidget *) 0x234c720
        handled_event = 39556272
        __PRETTY_FUNCTION__ = "IA__gtk_propagate_event"
#25 0x00007f23f597524b in IA__gtk_main_do_event (event=0x25b94b0)
    at /scratch/build-area/gtk+2.0-2.12.11/gtk/gtkmain.c:1556
        event_widget = (GtkWidget *) 0x23e5b80
        grab_widget = (GtkWidget *) 0x23e5b80
        window_group = (GtkWindowGroup *) 0x234c720
        rewritten_event = (GdkEvent *) 0x0
        tmp_list = <value optimized out>
        __PRETTY_FUNCTION__ = "IA__gtk_main_do_event"
#26 0x00007f23f55d6f8c in gdk_event_dispatch (source=<value optimized out>,
    callback=<value optimized out>, user_data=<value optimized out>)
    at /scratch/build-area/gtk+2.0-2.12.11/gdk/x11/gdkevents-x11.c:2351
        display = <value optimized out>
        event = <value optimized out>
#27 0x00007f23f3f36892 in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
No symbol table info available.
#28 0x00007f23f3f3a01d in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#29 0x00007f23f3f3a54d in g_main_loop_run () from
/usr/lib/libglib-2.0.so.0
No symbol table info available.
#30 0x00007f23f5975667 in IA__gtk_main () at
/scratch/build-area/gtk+2.0-2.12.11/gtk/gtkmain.c:1163
        tmp_list = (GList *) 0x1
        functions = (GList *) 0x0
        init = (GtkInitFunction *) 0x7fffff3c82c0
        loop = (GMainLoop *) 0x0
#31 0x0000000000471425 in ?? ()
No symbol table info available.
#32 0x0000000000472333 in ?? ()
No symbol table info available.
#33 0x00007f23f30d71a6 in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#34 0x0000000000409cb9 in ?? ()
No symbol table info available.
#35 0x00007fffff3c84e8 in ?? ()
No symbol table info available.
#36 0x000000000000001c in ?? ()
No symbol table info available.
#37 0x0000000000000001 in ?? ()
No symbol table info available.
#38 0x00007fffff3c9488 in ?? ()
No symbol table info available.
#39 0x0000000000000000 in ?? ()
No symbol table info available.

Good luck chief.

reassign 495005 libsane 1.0.19-15
severity 495005 normal
retitle 495005 [net] segfault with hpaio as the remote backend
thanks

Julien Danjou <acid@debian.org> wrote:

Hi,

That kind of segfault in the net protocol stack is usually due to a
standard violation by the remote backend.

The saned and net backend debug logs may help in tracking this
down. I'd take a corresponding network capture too, if possible.

JB.

At 1218654498 time_t, Julien BLACHE wrote:

Acually, I managed to get it work using saned -a, so I can't get any
debug value which might help, since inetd mode does not support debug.

Using saned from inetd still make the remote xsane/xscanimage to
ask for authentication and then segfault.

reassign 495005 hplip 2.8.6-2
retitle 495005 hpaio backend writes to fd 0, breaks saned/net
severity 495005 important
thanks

Julien Danjou <acid@debian.org> wrote:

Hi hplip folks,

This is a clear indication that the hpaio backend is writing to fd 0.

It's a bug in the code, either a fd declared static that's not
initialized to -1, or an fd explicitely initialized to 0, or, more
likely, the fd member of a struct that gets memset() after allocation
and is not properly initialized to -1 afterwards.

In any case, this breaks saned when run through inetd which is
guaranteed to render hpaio unusable over the network with the net
backend as whatever is written to fd 0 will confuse the hell out of
the net protocol stack.

JB.

forwarded 495005 https://bugs.launchpad.net/hplip/+bug/283699

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495005

----------  Forwarded Message  ----------

Subject: [Bug 283699] Re: hpaio backend writes to fd 0, breaks saned/net
Date: Thursday 16 October 2008
From: David Suffield <david.suffield@hp.com>
To: msp@debian.org

Show me the code :)

Hpaio has no io that writes to stdout. If you set SANE_DEBUG_DLL the
sanei_init_debug() will write to stderr.

-------------------------------------------------------

Aaron,

This is premature.

Whilst I can't show you the code, this still appears to be an issue for the
upstream user.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495005

Mark

Mark Purcell <msp@debian.org> wrote:

Hi,

The problem has been tracked down to libdbus complaining
unconditionally on stderr when it's not able to establish a connection
to the DBus daemon.

Consequently, I've added a workaround in saned CVS and sane-backends
1.0.19-26.

I have to had that this has been uncovered by a user digging deep
enough to reveal the problem. Enough said.

JB.

reassign 495005 libdbus-1-3
retitle 495005 "libdbus complaining unconditionally on stderr"
notforwarded 495005
thanks

----------  Forwarded Message  ----------

Subject: Bug#495005: [Bug 283699] Re: hpaio backend writes to fd 0, breaks saned/net
Date: Friday 03 April 2009
From: Julien BLACHE <jblache@debian.org>
To: Mark Purcell <msp@debian.org>

Mark Purcell <msp@debian.org> wrote:

Hi,

The problem has been tracked down to libdbus complaining
unconditionally on stderr when it's not able to establish a connection
to the DBus daemon.

Consequently, I've added a workaround in saned CVS and sane-backends
1.0.19-26.

I have to had that this has been uncovered by a user digging deep
enough to reveal the problem. Enough said.

JB.

-------------------------------------------------------

Mark Purcell wrote:

Mark,

maybe I'm missing something here:
Julien talks about fd 0, you about stderr, yet 0 != 2 ?

Could you actually show me, where (lib)dbus is at fault here?

Michael

Michael Biebl <biebl@debian.org> wrote:

Hi,

All three standard fds point to the network when run through inetd.

#516982 msg#35

Debug messages shouldn't be printed by the library unless it's a debug
build or the application asked for (allowed) them.

JB.

Sorry to resurrect an ancient bug report, but I'm trying to do some
triaging on src:dbus bugs.

which quotes a message from #20, further up the bug:

process 20186: arguments to dbus_connection_send() were incorrect,
assertion "connection != NULL" failed in file dbus-connection.c line 3099.
This is normally a bug in some application using the D-Bus library.

This is not a debug message, it's a warning of undefined behaviour having
been reached. In the default upstream configuration of libdbus it would
immediately have been followed by abort() (although Debian's libdbus is
patched to make these "checks" non-fatal by default; it isn't entirely
clear to me why this was done, and one day I might take that patch out).
Think of it as analogous to how glibc writes to stderr when it detects
memory corruption.

Something in the process in question is calling
dbus_connection_send(NULL, ?, ?), which is considered to be invalid in
the same way as (for example) fprintf(NULL, "hello") (which segfaults,
at least on my system).

If users of libdbus don't want undefined behaviour (which could include
messages on stderr, abort(), NULL pointer dereferences or whatever) then
they should not pass NULL to a function that is conceptually a method on
a (non-NULL) connection.

From comments on #516982 it seems that the cause is failure to connect to
the dbus-daemon, so dbus_bus_get() or dbus_bus_get_private() returned
NULL. The correct response to that happening is to stop trying to
interact with D-Bus, and either exit unsuccessfully (if interacting with
D-Bus is a required part of this program's functionality) or skip the
D-Bus bits (if interacting with D-Bus is not critical for this program).

Regards,
    smcv