On Tue, Jun 15, 2010 at 2:55 AM, Ross Finlayson <finlay...@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().
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
