[Live-devel] RTSP server hang

Ross Finlayson finlayson at live555.com
Tue Jun 15 02:55:16 PDT 2010


I've now installed a new version (2010.06.15) of the code that 
completely removes the "blockUntilReadable()" function.  This means 
that "readSocket()" no longer calls "select()", which
should improve the performance of both client and server applications.


>On a related note, here's one other hack I had to add to prevent crashing:
>
>void 
>RTSPServer::RTSPClientSession::handleAlternativeRequestByte1(u_int8_t 
>requestByte) {
>   // Add this character to our buffer; then try to handle the data 
>that we have buffered so far:
>   if (fRequestBufferBytesLeft == 0) return;
>   if (fRequestBytesAlreadySeen >= RTSP_BUFFER_SIZE ) return;    // 
>hack: don't let us overflow fRequestBuffer, and there's some bug
>                                                                 // 
>with sessions containing multiple subsessions, when streaming over
>                                                                 // 
>TCP that causes this to fail miserably.
>   fRequestBuffer[fRequestBytesAlreadySeen] = requestByte;
>   handleRequestBytes(1);
>}
>
>
>...I previously reported this.  When there are multiple sessions 
>being streamed that contain both audio and video (i.e. multiple 
>subsessions) over TCP, sometimes the server will crash with an 
>access violation by walking off the end of fRequestBuffer.  I do not 
>understand the crash; I do know that this code prevents it.

I don't understand why the "hack" line should be necessary, because 
"handleRequestBytes()" should already be testing for buffer overflow. 
However, this newest release of the code improves the handling of 
RTP/RTCP/RTSP-over-TCP, so I'm hoping that it happened to fix the bug 
as well.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


More information about the live-devel mailing list