[Live-devel] Crash in RTSPServer.cpp

[Jeremy Noring]

On Fri, May 7, 2010 at 9:28 AM, Jeremy Noring <jnoring at logitech.com> wrote:

> On Fri, Apr 30, 2010 at 4:19 PM, Ross Finlayson <finlayson at live555.com>wrote:
>
>>
>> It would be nice to find a simple, repeatable sequence of client
>> operations that cause the crash.  E.g., does crash ever happen if there are
>> two complete "DESCRIBE, SETUP, SETUP, PLAY, TEARDOWN" sequences in order
>> (i.e., not overlapping), or does it occur only when two such sequences
>> overlap?  Once you've found a repeatable situation that causes the crash,
>> then you could also test with RTP-over-UDP, and with "reuseFirstSource" set
>> to False.
>
>
> Okay, I did more testing.  Definitely the issue is overlapping DESCRIBE,
> SETUP, SETUP, PLAY, TEARDOWN sequences.  And for me, the problem was
> exacerbated by the fact that my client would connect to the server _twice_
> (once to fetch media types, then a TEARDOWN, and again to start pulling
> media).  I changed it so my code connects a single time and I can no longer
> reproduce the crash.
>
> So I think there is a bug in there somewhere, and it definitely involves
> overlapped sequences like that.  I did try to isolate it with mediaServer
> and openRTSP, but...haven't had a lot of luck.  I'll let you know if I find
> out anything else.
>

We're still having issues with this, so I had to do more testing.  Instead
of hitting with our client application, I used "openRTSP -t -d 1 <url>" to
hit our RTSP server.  The RTSP server is configured to reuse sources.  This
time, I did managed to reproduce the crash:

 >  RTSPServer::RTSPClientSession::handleAlternativeRequestByte1(unsigned
char requestByte='T')  Line 322 + 0xf bytes    C++
     RTSPServer::RTSPClientSession::handleAlternativeRequestByte(void *
instance=0x06010868, unsigned char requestByte='T')  Line 317    C++
     SocketDescriptor::tcpReadHandler(SocketDescriptor *
socketDescriptor=0x05fdc2c0, int mask=2)  Line 357 + 0x14 bytes    C++
     BasicTaskScheduler::SingleStep(unsigned int maxDelayTime=0)  Line 115 +
0x11 bytes    C++
     BasicTaskScheduler0::doEventLoop(char * watchVariable=0x01f85698)  Line
77    C++

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;
  fRequestBuffer[fRequestBytesAlreadySeen] = requestByte;  // FAILED HERE
  handleRequestBytes(1);
}

fRequestBytesAlreadySeen is 3452816845, causing an access violation since
fRequestBuffer is only 10 KB.  I looked at the state of "this":

-        this    0x06010868 {fOurServer={...} fOurSessionId=3452816845
fOurServerMediaSession=0xcdcdcdcd ...}    RTSPServer::RTSPClientSession *
const
+        __vfptr    0xcdcdcdcd    *
+        fOurServer    {fServerSocket=??? fServerPort={...} fAuthDB=???
...}    RTSPServer &
        fOurSessionId    3452816845    unsigned int
+        fOurServerMediaSession    0xcdcdcdcd {fIsSSM=???
fSubsessionsHead=??? fSubsessionsTail=??? ...}    ServerMediaSession *
        fClientSocket    -842150451    int
+        fClientAddr    {sin_family=-12851 sin_port=52685 sin_addr={...}
...}    sockaddr_in
        fLivenessCheckTask    0xcdcdcdcd    void *
+        fRequestBuffer    0x06010890
"ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ"
unsigned char [10000]
        fRequestBytesAlreadySeen    3452816845    unsigned int
        fRequestBufferBytesLeft    3452816845    unsigned int
+        fLastCRLF    0xcdcdcdcd <Bad Ptr>    unsigned char *
+        fResponseBuffer    0x06012fac
"ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ"
unsigned char [10000]
        fIsMulticast    0    unsigned int
        fSessionIsActive    0    unsigned int
        fStreamAfterSETUP    4261281277    unsigned int
+        fCurrentAuthenticator    {fRealm=0xabababab <Bad Ptr>
fNonce=0x00000000 <Bad Ptr> fUsername=0x00000000 <Bad Ptr> ...}
Authenticator
        fTCPStreamIdCount    120 'x'    unsigned char
        fNumStreamStates    100699448    unsigned int
+        fStreamStates    0x00000000 {subsession=??? streamToken=??? }
RTSPServer::RTSPClientSession::streamState *

This object is in a very weird state.  the 0xcdcdcdcd values correspond with
freshly allocated memory from the CRT (see
http://www.nobugs.org/developer/win32/debug_crt_heap.html), so it appears to
be an object that was just allocated--but this makes little sense given the
implementation of RTSPClientSession.

I'm not sure if this extra information helps or not.  I'm going to work on
running it under devpartner to see if anything else falls out of the
woodwork.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100511/089d85ec/attachment.html>