[Bug 651] SCO 3.2v4.2 and OpenSSH 3.7.1p1 --> connection hangs and does not close (ssh2 only)

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=651

           Summary: SCO 3.2v4.2 and OpenSSH 3.7.1p1 --> connection hangs and
                    does not close (ssh2 only)
           Product: Portable OpenSSH
           Version: 3.7p1
          Platform: All
        OS/Version: other
            Status: NEW
          Severity: major
          Priority: P2
         Component: sshd
        AssignedTo: openssh-bugs at mindrot.org
        ReportedBy: vikashb at comparexafrica.co.za


When executing a remote command or when exiting from a shell,
the ssh connection hangs indefinitely, the only way to close the session
is [crontol]+[c] even [~][.] does not work.

This problem only exists when using ssh2 connections.

the server side debug(-d -d -d) :

debug1: Received SIGCHLD.
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf_empty delayed efd 12/(0)
debug2: notify_done: reading
debug2: channel 0: read 0 from efd 12
debug2: channel 0: closing read-efd 12
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug2: channel 0: input drain -> closed
--->hangs<---
--------------------------------------------

below is a backtrace from gdb:
(gdb) s
326             ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp);
(gdb) l
321                     tv.tv_usec = 1000 * (max_time_milliseconds % 1000);
322                     tvp = &tv;
323             }
324
325             /* Wait for something to happen, or the timeout to expire. */
326             ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp);
327
328             if (ret == -1) {
329                     memset(*readsetp, 0, *nallocp);
330                     memset(*writesetp, 0, *nallocp);
(gdb) bt
#0  wait_until_can_do_something (readsetp=0x7ffff8d8, writesetp=0x7ffff8d4,
    maxfdp=0x7ffff8d0, nallocp=0x7ffff8cc, max_time_milliseconds=0)
    at serverloop.c:326
#1  0x8bfc in server_loop2 (authctxt=0x42eaf8) at serverloop.c:770
#2  0x104bb in do_authenticated2 (authctxt=0x42eaf8) at session.c:2152
#3  0xcc19 in do_authenticated (authctxt=0x42eaf8) at session.c:216
#4  0x2eaa in main (ac=6, av=0x7ffffe1c) at sshd.c:1506
(gdb) s

I have no idea how to resolve this.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.