[Live-devel] RTSP server hang

[Jeremy Noring]

On Tue, Jun 15, 2010 at 2:55 AM, Ross Finlayson <finlayson at live555.com>wrote:

> 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.


It fails on this line in handleAlternativeRequestByte1:

fRequestBuffer[fRequestBytesAlreadySeen] = requestByte;

...so no, it does not test for buffer overflow.  For whatever reason,
fRequestBuffer gets set to a very large number (i.e. greater than 10K),
which causes this function to crash with an access violation.  It doesn't
have anything to do with handleRequestBytes().
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100615/07d77a4e/attachment-0001.html>