[9fans] bug in ape? - Plan9

This is a discussion on [9fans] bug in ape? - Plan9 ; The ssh2 always fails with copious data. I.e. lots of data comes in, and the proc reading from the socket at some point fails. I see this go by: pread(4, 0x06000508, 8192, 4294967295) return value: 7520 data: 0x06000508, 7520 Note ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: [9fans] bug in ape?

  1. [9fans] bug in ape?

    The ssh2 always fails with copious data. I.e. lots of data comes in,
    and the proc reading from the socket at some point fails.

    I see this go by:
    pread(4, 0x06000508, 8192, 4294967295)
    return value: 7520
    data: 0x06000508, 7520

    Note the offset is x508, and we read 7520 bytes, which, if the buffer
    is 8k, is an overrun.

    The ape code is this:
    static void
    _copyproc(int fd, Muxbuf *b)
    {
    unsigned char *e;
    int n;
    int nzeros;

    e = &b->data[PERFDMAX];
    for(; {
    /* make sure there's room */
    lock(&mux->lock);
    if(e - b->putnext < READMAX) {
    if(b->getnext == b->putnext) {
    b->getnext = b->putnext = b->data;
    unlock(&mux->lock);
    } else {
    /* sleep until there's room */
    b->roomwait = 1;
    unlock(&mux->lock);
    _RENDEZVOUS((unsigned long)&b->roomwait, 0);
    }
    } else
    unlock(&mux->lock);
    /*
    * A Zero-length _READ might mean a zero-length write
    * happened, or it might mean eof; try several times to
    * disambiguate (posix read() discards 0-length messages)
    */
    nzeros = 0;
    do {
    n = _READ(fd, b->putnext, READMAX); <<<<<<<<<============= this line
    if(b->fd == -1) {
    _exit(0); /* we've been closed */
    }
    } while(n == 0 && ++nzeros < 3);
    lock(&mux->lock);

    note the _READ above. It always calls with READMAX. I don't know yet
    what putnext can be (in range), but this is a data point. I am posting
    this as there may be someone who has seen it before.

    ron

  2. Re: [9fans] bug in ape?

    On Dec 19, 2007 5:22 AM, ron minnich wrote:
    > The ssh2 always fails with copious data. I.e. lots of data comes in,
    > and the proc reading from the socket at some point fails.
    >
    > I see this go by:
    > pread(4, 0x06000508, 8192, 4294967295)
    > return value: 7520
    > data: 0x06000508, 7520
    >
    > Note the offset is x508, and we read 7520 bytes, which, if the buffer
    > is 8k, is an overrun.


    The buffer is PERFDMAX bytes, which appears to be 2*READMAX. READMAX
    is 8192 based on what you've posted. In any case, the whole point of
    the condition at the start of the loop (e - b->putnext < READMAX) is
    to guarentee there is READMAX bytes left in the buffer.
    -sqweek

  3. Re: [9fans] bug in ape?

    On Dec 18, 2007 6:51 PM, sqweek wrote:

    > The buffer is PERFDMAX bytes, which appears to be 2*READMAX. READMAX
    > is 8192 based on what you've posted. In any case, the whole point of
    > the condition at the start of the loop (e - b->putnext < READMAX) is
    > to guarentee there is READMAX bytes left in the buffer.


    yeah, I misread the code.

    We have found the problem. At some point the plan 9 client is sending
    a packet to the linux sshd server that it really hates. The server
    sends back an error with something like "bad message size 174585434"
    which, yes, looks bad.

    So we're building an ssdh from source to see what's going on.

    thanks

    ron

  4. Re: [9fans] bug in ape?

    Ron, you are right... I wrote a simple test program that makes a
    socket and selects on it and then calls recv() if it is readable.
    Here is my stacktrace:

    acid: lstk()
    read(nbytes=0xa,buf=0xdfffeb7e,d=0x4)+0x0 /sys/src/ape/lib/ap/plan9/read.c:10
    noblock=0x0
    n=0x9
    recv(flags=0x0,fd=0x4,a=0xdfffeb7e,n=0xa)+0x3e /sys/src/ape/lib/bsd/send.c:30
    main()+0x153 /tmp/socktest/a.c:39
    fd=0x4
    a=0x50000002
    s=0x10
    x=0x0
    _main+0x26 /sys/src/ape/lib/ap/386/main9.s:12

    It calls the right read() from /sys/src/ape/lib/ap/plan9/read.c. But
    i still dont understand why the stacktrace you posted shows recv() calling
    read from /sys/src/libc/9sys/read.c :-( How can that happen?

    >> pread()+0x7 /sys/src/libc/9syscall/pread.s:5
    >> read(fd=0x5,buf=0x110414,n=0x1000)+0x2f /sys/src/libc/9sys/read.c:7
    >> recv(flags=0x0,fd=0x5,a=0x110414,n=0x1000)+0x3e
    >> /sys/src/ape/lib/bsd/send.c:30
    >> libssh2_packet_read(session=0x1102f8)+0x176
    >> /usr/bootes/libssh2/libssh2-0.18/src/transport.c:326
    >> libssh2_channel_read_ex(channel=0x114460,buflen=0x 1000,stream_id=0x0,buf=0xdfffdee8)+0x2a7
    >>
    >> /usr/bootes/libssh2/libssh2-0.18/src/channel.c:1442
    >> fromnet(c=0x114460,s=0x1102f8)+0x2e
    >> /usr/bootes/libssh2/libssh2-0.18/clients/ssh2.c:75
    >> main(argc=0x2,argv=0xdfffef94)+0x47c
    >> /usr/bootes/libssh2/libssh2-0.18/clients/ssh2.c:253
    >> _main+0x31 /sys/src/libc/386/main9.s:16


    --
    cinap


+ Reply to Thread