#378 thru TCP without pseudo-tty => UNIX error 14 bad address

open
Jörg Höhle
clisp (525)
5
2006-11-09
2006-11-08
No

When clisp is invoked thru bare ssh, it fails. We
need to use the -t
option to ssh to force pseudo-tty allocation for clisp.
I see no good
reason why clisp couldn't detect that it isn't
connected to a pty and
avoid to use an unapplyable API, after all, it does it
right with
files and pipes:

# (not localhost)
$ ssh janus-1 clisp --version
stty: standard input: Invalid argument
GNU CLISP 2.39 (2006-07-16) (built 3365477833) (memory
3365480464)
Software: GNU C 3.3 20030226 (prerelease) (SuSE Linux)
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith
-Wimplicit -Wreturn-type -Wmissing-declarations
-Wno-sign-compare -O2 -fexpensive-optimizations
-falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. -x none
libcharset.a libavcall.a libcallback.a -lreadline
-lncurses -ldl -lsigsegv -L/usr/X11R6/lib
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES
GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.2
libreadline 4.3
Features:
(READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP
CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER
SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI
GETTEXT UNICODE BASE-CHAR=CHARACTER PC386
UNIX)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory:
/usr/local/languages/clisp-2.39-pjb1-regexp/lib/clisp/
User language: ENGLISH
Machine: I686 (I686) janus-1.janus.afaa.asso.fr
[195.114.85.145]
[1]>
*** - UNIX error 14 (EFAULT): Bad address

(ext:quit)

[pjb@thalassa httpd]$ ssh -t janus-1 clisp --version
GNU CLISP 2.30 (released 2002-09-15) (built on
bragg.suse.de [127.0.0.2])
Features:
(CLOS LOOP COMPILER CLISP ANSI-CL COMMON-LISP LISP=CL
INTERPRETER SOCKETS
GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI UNICODE
BASE-CHAR=CHARACTER
SYSCALLS PC386 UNIX)
Connection to janus-1 closed.

[pjb@thalassa httpd]$ ls -l | clisp --version 2>
/tmp/errs | cat
GNU CLISP 2.39 (2006-07-16) (built 3364813332) (memory
3364813914)
Software: GNU C 3.3 20030226 (prerelease) (SuSE Linux)
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith
-Wimplicit -Wreturn-type -Wmissing-declarations
-Wno-sign-compare -O2 -fexpensive-optimizations
-falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. -x none
libcharset.a libavcall.a libcallback.a -lreadline
-lncurses -ldl -lsigsegv -L/usr/X11R6/lib
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES
GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.4
libreadline 4.3
Features:
(READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP
CLISP ANSI-CL COMMON-LISP
LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS
LOGICAL-PATHNAMES SCREEN FFI
GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory:
/usr/local/languages/clisp-2.39-pjb1-regexp/lib/clisp/
User language: ENGLISH
Machine: I686 (I686) thalassa.informatimago.com
[62.93.174.79]

Discussion

1 2 3 > >> (Page 1 of 3)
  • Jörg Höhle
    Jörg Höhle
    2006-11-08

    Logged In: YES
    user_id=377168

    Confirmed.
    Two things are remarkable about the gdb backtrace
    Third, stream.d:finish_tty_output() looks strange. It does
    both fsync() and ioctl().
    I'd have expected either one or the other.
    Maybe the #ifdef are broken? Or return; on success is
    missing, before trying the next method in sequence?

    1. a link to [ Bug #1220548 ] -- See how reset(count=<broken
    value>) is found on the stack.
    #11 0x08065b70 in interpret_bytecode_ (closure=0x20385cfe,
    codeptr=0x202aa5dc, byteptr_in=0x42 <Address 0x42 out of
    bounds>)
    at eval.d:7077
    #12 0x080667e8 in funcall_closure (closure=0xb7b24084,
    args_on_stack=<value optimized out>) at eval.d:5771
    #13 0x080dab73 in driver () at debug.d:477
    #14 0x0805b3ec in reset (count=3081912564) at eval.d:517
    #15 0x080665b7 in interpret_bytecode_ (closure=0x20387996,
    codeptr=0x20343fc4, byteptr_in=0x20344004
    "\022\002\031\005")
    at eval.d:7608

    2. the problem itself:
    #25 0x0805d111 in funcall_subr (fun=0x81a0e06,
    args_on_stack=0) at eval.d:5325
    #26 0x080dd8e6 in signal_and_debug (condition=0xbfbb3e10) at
    error.d:204
    #27 0x080ddb4b in end_error (stackptr=<value optimized out>,
    start_driver_p=true) at error.d:317
    #28 0x080dfa7b in OS_error () at errunix.d:688
    #29 0x080851f7 in low_finish_output_unbuffered_handle
    (stream=0xbfbb3e10)
    at stream.d:3493
    #30 0x08085c7d in finish_output_unbuffered (stream=0x2038709e)
    at stream.d:5678
    #31 0x08096954 in fresh_line (stream_=0xb7b24008) at
    stream.d:16607
    #32 0x080a1b0d in C_fresh_line () at io.d:10610
    #33 0x0805d18c in funcall_subr (fun=0x81a19e6,
    args_on_stack=1) at eval.d:5330
    #34 0x08052884 in quit () at spvw.d:3423
    #35 0x08068c61 in C_exit () at control.d:15

    stream.d:3493 contains
    local void finish_tty_output (Handle handle)
    ...
    #if defined(UNIX_TERM_TERMIOS) && defined(TCGETS) &&
    defined(TCSETSW)
    {
    var struct termios term_parameters;
    if (!( ( ioctl(handle,TCGETS,&term_parameters) ==0)
    && ( ioctl(handle,TCSETSW,&term_parameters)
    ==0))) {
    if (!((errno==ENOTTY)||(errno==EINVAL)))
    { OS_error(); } # no TTY: OK, report other Error
    }
    }
    Actually, tcdrain() is unsupported (gdb line number must be
    out of sync) and yields (-1,14).

    4. It's curious that this only appears with --version.
    (finish-output *terminal-io*) also raises the error within ssh.
    Obviously, finish-output is almost never called.

    5. Maybe a bug should be reported to ssh, that tcdrain()
    yields (-1,14)
    Could you please investigate other situations (inside socket
    etc.) using this code?
    (use-package "FFI")
    (def-call-out tcdrain (:arguments (fd int)) (:return-type
    int) (:library :default))
    (locally (declare (compile)) (setf errno 0) (values (tcdrain
    1) errno))

     
  • Jörg Höhle
    Jörg Höhle
    2006-11-08

    Logged In: YES
    user_id=377168

    thank you for your bug report.
    the bug has been fixed in the CVS tree.
    you can either wait for the next release (recommended)
    or check out the current CVS tree (see http://clisp.cons.org\)
    and build CLISP from the sources (be advised that between
    releases the CVS tree is very unstable and may not even build
    on your platform).

     
  • Jörg Höhle
    Jörg Höhle
    2006-11-08

    • assigned_to: haible --> hoehle
    • status: open --> closed-fixed
     
  • Sam Steingold
    Sam Steingold
    2006-11-08

    • status: closed-fixed --> open-fixed
     
  • Sam Steingold
    Sam Steingold
    2006-11-08

    Logged In: YES
    user_id=5735

    there are two separate issues here:
    1. under SSH, make_terminal_io() should call
    make_twoway_stream() instead of make_terminal_stream().
    this requires replacing regular_handle_p() calls with
    isatty() there.
    the risk is that in some obscure cases (cygwin xterm &c)
    this would lose us readline).
    2. FINISH-OUTPUT does not list exceptional situations due to
    OS interaction, so it makes sense to ignore all errors in
    finish_tty_output() et al.
    the risk is that we may miss some bugs this way.

     
  • Sam Steingold
    Sam Steingold
    2006-11-08

    • assigned_to: hoehle --> haible
    • status: open-fixed --> open
     
  • Sam Steingold
    Sam Steingold
    2006-11-08

    • assigned_to: haible --> hoehle
    • status: open --> closed-fixed
     
  • Sam Steingold
    Sam Steingold
    2006-11-08

    Logged In: YES
    user_id=5735

    sorry Jorg, my comment crossed your.
    also, please avoid '# ' comments in new code.

     
  • Jörg Höhle
    Jörg Höhle
    2006-11-09

    • status: closed-fixed --> open-fixed
     
  • Jörg Höhle
    Jörg Höhle
    2006-11-09

    Logged In: YES
    user_id=377168

    1. Indeed, I was wondering why finish_tty_output would be
    concerned when obviously there's no tty.
    Actually, this may be the reason:
    local void low_finish_output_unbuffered_handle (object stream) {

    finish_tty_output(TheHandle(TheStream(stream)->strm_ochannel));

    2. I've learnt not to deduce anything from missing
    exceptional situations in the CLHS. E.g. WRITE does not
    mention exceptional I/O situations. Is that an argument to
    ignore them?

    My first patch was broken, I've a fix pending -- but that
    does not solve the ssh issue.

    Another solution path is to explore why only --version is
    affected, i.e. why that invokes (finish-output
    *terminal-io*) while a normal interactive session does not.

    Note that even after applying my patch, within ssh:
    [1]> (finish-output *terminal-io*)
    *** - UNIX error 14 (EFAULT): Bad address
    The following restarts are available:
    ABORT :R1 ABORT
    Break 1 [2]> (finish-output *terminal-io*)

    *** - UNIX error 14 (EFAULT): Bad address

    *** - UNIX error 14 (EFAULT): Bad address

    *** - UNIX error 14 (EFAULT): Bad address

    *** - UNIX error 14 (EFAULT): Bad address

    Weird, isn't it?

     
1 2 3 > >> (Page 1 of 3)