From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <47677773.30607@gmx.de>
Date: Tue, 18 Dec 2007 08:32:03 +0100
From: Kernel Panic <cinap_lenrek@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.12) Gecko/20050915
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] a question on APE
References: <13426df10712171736i60f181aax4fdf2cf57594fa87@mail.gmail.com>
In-Reply-To: <13426df10712171736i60f181aax4fdf2cf57594fa87@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 1c0fce7a-ead3-11e9-9d60-3106f5b1d025

ron minnich wrote:

>we're doing some work here with Andrey's port of ssh2. It *almost*
>works. But I'm seeing a stack trace I don't understand.
>
>I can't give you all the details -- it's ssh, therefore it is pretty
>awful -- but here is the short form: There is a proc called fromnet()
>which has this inner loop:
>	for(;;){
>		if((n = libssh2_channel_read(c, buf, Bufsize)) > 0)
>			write(1, buf, n);
>		else
>			goto Donenet;
>	}
>
>When this proc is entered, ape has forked off two procs to handle the
>fd 'c'. From the fromnet function, we see the libssh2_channel_read
>does a select. here is where I get confused. The stk() for the two
>procs looks like this:
>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=0x1000,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
>
>The the read on fd 5. That's the socket. Here is the other proc.
>
>_PREAD()+0x7 /sys/src/ape/lib/ap/syscall/_PREAD.s:5
>_READ(fd=0x5,buf=0x600003c,n=0x2000)+0x2f /sys/src/ape/lib/ap/plan9/9read.c:10
>_copyproc(b=0x6000028,fd=0x5)+0x86 /sys/src/ape/lib/ap/plan9/_buf.c:166
>_startbuf(fd=0x5)+0x1dd /sys/src/ape/lib/ap/plan9/_buf.c:107
>select(timeout=0xdfffde90,rfds=0xdfffde80,wfds=0x0,efds=0x0,nfds=0x6)+0xe9
>/sys/src/ape/lib/ap/plan9/_buf.c:292
>libssh2_waitsocket(session=0x1102f8,seconds=0x0)+0x7b
>/usr/bootes/libssh2/libssh2-0.18/src/packet.c:1054
>libssh2_channel_read_ex(channel=0x114460,buflen=0x1000,stream_id=0x0,buf=0xdfffdee8)+0x69
>/usr/bootes/libssh2/libssh2-0.18/src/channel.c:1408
>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
>
>ok, I think this stack is a bit messed up, since I don't see how we
>can have the coyproc in the call chain from select(), but ... is it?
>
>  
>
Plan9 has no select functionality. Select is emulated in APE by forking 
a childproc that reads an fd and
fills a buffer (on a shared memory area). Read() should then pick up the 
data from the buffer and
wakeup the reader proc if it sleeps (because the buffer got filled up). 
Select() will startup such a
reader proc (startbuf()) if it is not already "bufferd" and then check 
if the buffer has data available,
so the stacktrace looks valid to me.

Maybe the bufferd filedescriptors doesnt work with the recv() call and 
are only implemented for read()?
I think you should find some kind of switch in read() that checks if the 
fd is bufferd and then calls
some _buf.c function that copies the data from the buffer.
Maybe this is missing for recv()?

>I realize there is very little information here, sorry ... here's what
>is bothering me. It seems we have two procs hanging on a read on fd 5.
>I think the copyproc and some other proc are in conflict but ... I am
>unsure. The problems we are seeing might be explained by the wrong
>proc grabbing output at the wrong time -- it feels like a race
>condition. And acid trips we can take to hammer this one down?
>
>Anyone ever done a select on a socket in ape?
>
>  
>