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