Re: PR_Read fails second time on Solaris 8
"VinuT" <[email protected]> Wed, 3 Jun 2009 19:31:48 -0400
| Newsgroups | gmane.comp.mozilla.devel.nspr |
|---|---|
| Message-ID | <[email protected]> |
This problem is not due to NSPR. We have identified it as a source in SSL server I tried using the suggestions below i.e #if defined(SOLARIS_X) and icluding recv instead of read. but i still got same behaviour. So i did a packet capture on the SSL server and saw that the server was sending TCP FIN,ACK packets in between. When it did this, PR_Read would return without the complete data. However if the server sends a ACK,ACK packet, everything seems fine. And we tested it against some other SSL servers running on different machines. There everything seems to work fine. Thanks for your help Wan-Teh and everyone "Wan-Teh Chang" <[email protected]> wrote in message news:[email protected]... > On Wed, May 27, 2009 at 3:26 PM, Vinu <[email protected]> > wrote: >> Hi Nelson, >> >> Yes, I did some more tests. >> >> The server sends the data and then closes the connection(becuase we use >> HTTP >> Connection:close and not Keep-Alive). >> >> But shouldnt PR_Read return the entire data and then only return >> 0(becuase >> the connection is closed). >> How can it return 0, before all the data has been returned to the >> application. >> >> BTW this same code on Linux and Windows works fine. > > I'm afraid that you'll need to debug this yourself because we > can't reproduce this problem. The relevant file is > mozilla/nsprpub/pr/src/pthreads/ptio.c. Look at pt_Recv and > pt_recv_cont. > > The implementation of PR_Read is essentially the same between > Solaris and Linux, with one difference -- as a performance optimization, > we use read() instead of recv() on Solaris only. See: > http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/nsprpub/pr/src/pthreads/ptio.c&rev=3.113&mark=1858,1863,1865#1830 > http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/nsprpub/pr/src/pthreads/ptio.c&rev=3.113&mark=779,786,789#772 > > Please try changing those two instances of > #if defined(SOLARIS) > to > #if defined(SOLARIS_X) > (which disables the Solaris code), and rebuild NSPR. Does that > make the problem go away on Solaris? > > If that fixes the problem, I have to admit that I don't understand > why because read() should also work with sockets. > > If that doesn't fix the problem, you can add printf statements > or use a debugger to find out what the read() or recv() calls > return, etc. > > Wan-Teh