On Fri, May 7, 2010 at 9:28 AM, Jeremy Noring <span dir="ltr"><<a href="mailto:jnoring@logitech.com" target="_blank">jnoring@logitech.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On Fri, Apr 30, 2010 at 4:19 PM, Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com" target="_blank">finlayson@live555.com</a>></span> wrote:<br></div><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
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.</blockquote>
</div><div><br>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.<br>
<br>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.<br>
</div></div></blockquote><div><br>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:<br>
<br> > RTSPServer::RTSPClientSession::handleAlternativeRequestByte1(unsigned char requestByte='T') Line 322 + 0xf bytes C++<br> RTSPServer::RTSPClientSession::handleAlternativeRequestByte(void * instance=0x06010868, unsigned char requestByte='T') Line 317 C++<br>
SocketDescriptor::tcpReadHandler(SocketDescriptor * socketDescriptor=0x05fdc2c0, int mask=2) Line 357 + 0x14 bytes C++<br> BasicTaskScheduler::SingleStep(unsigned int maxDelayTime=0) Line 115 + 0x11 bytes C++<br>
BasicTaskScheduler0::doEventLoop(char * watchVariable=0x01f85698) Line 77 C++<br><br>void RTSPServer::RTSPClientSession::handleAlternativeRequestByte1(u_int8_t requestByte) {<br>
// Add this character to our buffer; then try to handle the data that we have buffered so far:<br> if (fRequestBufferBytesLeft == 0) return;<br> fRequestBuffer[fRequestBytesAlreadySeen] = requestByte; // FAILED HERE<br>
handleRequestBytes(1);<br>}<br></div></div><br>fRequestBytesAlreadySeen is 3452816845, causing an access violation since fRequestBuffer is only 10 KB. I looked at the state of "this": <br><br>- this 0x06010868 {fOurServer={...} fOurSessionId=3452816845 fOurServerMediaSession=0xcdcdcdcd ...} RTSPServer::RTSPClientSession * const<br>
+ __vfptr 0xcdcdcdcd *<br>+ fOurServer {fServerSocket=??? fServerPort={...} fAuthDB=??? ...} RTSPServer &<br> fOurSessionId 3452816845 unsigned int<br>+ fOurServerMediaSession 0xcdcdcdcd {fIsSSM=??? fSubsessionsHead=??? fSubsessionsTail=??? ...} ServerMediaSession *<br>
fClientSocket -842150451 int<br>+ fClientAddr {sin_family=-12851 sin_port=52685 sin_addr={...} ...} sockaddr_in<br> fLivenessCheckTask 0xcdcdcdcd void *<br>+ fRequestBuffer 0x06010890 "ΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝ" unsigned char [10000]<br>
fRequestBytesAlreadySeen 3452816845 unsigned int<br> fRequestBufferBytesLeft 3452816845 unsigned int<br>+ fLastCRLF 0xcdcdcdcd <Bad Ptr> unsigned char *<br>+ fResponseBuffer 0x06012fac "ΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝΝ" unsigned char [10000]<br>
fIsMulticast 0 unsigned int<br> fSessionIsActive 0 unsigned int<br> fStreamAfterSETUP 4261281277 unsigned int<br>+ fCurrentAuthenticator {fRealm=0xabababab <Bad Ptr> fNonce=0x00000000 <Bad Ptr> fUsername=0x00000000 <Bad Ptr> ...} Authenticator<br>
fTCPStreamIdCount 120 'x' unsigned char<br> fNumStreamStates 100699448 unsigned int<br>+ fStreamStates 0x00000000 {subsession=??? streamToken=??? } RTSPServer::RTSPClientSession::streamState *<br>
<br>This object is in a very weird state. the 0xcdcdcdcd values correspond with freshly allocated memory from the CRT (see <a href="http://www.nobugs.org/developer/win32/debug_crt_heap.html" target="_blank">http://www.nobugs.org/developer/win32/debug_crt_heap.html</a>), so it appears to be an object that was just allocated--but this makes little sense given the implementation of RTSPClientSession.<br>
<br>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.<br>
<br><br>