<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><base href="x-msg://780/"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>2 adjustments to the library allow me to tiptoe thru the call stack avoiding accessing destroyed or already deleted members and unwind this stack.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I do not suggest these at all, they are a hack, but it confirms for me what is happening with the call stack.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Add an exit label with a dummy command at the end of the while loop beyond the onReceive call to avoid it.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>First modify RTCP.cpp<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>….<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> onReceive(typeOfPacket, totPacketSize, reportSenderSSRC);<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> exit:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> int dummy = 0;<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> } while (0);<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>}<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Then after calling the bye handler jump to it<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> (*byeHandler)(fByeHandlerClientData);<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> goto exit;<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> }<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>This gest me almost all the way out of the stack unwind. But when I return to RTSPClient::playMediaSession after the call to the event loop there is a “delete[] fResultString”<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>It has already been deleted and causes a access violation so commenting it out gets me thru, returning false which allows the application to continue unscathed.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>In GCC, or Microsoft release mode this may not show up as they zero out memory for you, but in debug mode a special non-null value is placed in the heap to signify bad pointer. Either way we cannot depend on it because it is not part of c++.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> live-devel-bounces@ns.live555.com [mailto:live-devel-bounces@ns.live555.com] <b>On Behalf Of </b>Jeff Shanab<br><b>Sent:</b> Saturday, November 19, 2011 8:51 AM<br><b>To:</b> LIVE555 Streaming Media - development & use<br><b>Subject:</b> Re: [Live-devel] Access violation crash in rtspclient<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I know that 99% of the time it is ‘adjustments to’ and ‘missuse’ that are the problems people have with using live555, but unless they changed the way CPU’s work, we do have an issue.<o:p></o:p></p><p class=MsoNormal>(This issue is avoided in openRTSP by just exiting the process before the access violation could hit.)<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It boils down to calling the destructor of a class from a member in the class puts us in undefined territory. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I call your attention to RTCP.cpp from 11/08/2011<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In the switch statement in incomingReportHandler1 at line 511, we handle the case of an incoming “BYE” message.<o:p></o:p></p><p class=MsoNormal>On line 525 we save the program counter and create a new stack frame to handle the jump long to the bye handler function. As you say and as the openRTSP does Medium::close is called and this calls the DOTR on the very instance we are calling from. On completion of this call the program counter is restored and execution resumes at line 526. The program counter is still valid and so is the CODE segment in memory, only the DATA segment holding the instance was erased in the dtor.<o:p></o:p></p><p class=MsoNormal>The break on 532 exits the switch taking us to line 542. It passes all test and gets to 583 containing valid stack data and there is nothing to stop it from calling onReceive.<o:p></o:p></p><p class=MsoNormal>In onReceive, line 593, it tries to access the memory that was returned to the OS during the dtor and an access violation attempting to read that memory is thrown.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For my use case of the live555 libraries, I cannot take the process approach. It would require a re-arching of an existing project and the result would not work well cross platform. I have upto hundreds if not thousands of connected sources and as many, plus another few hundred, sinks. I have status pages that show status of these streams and notifications on some if they fail. Even then with the dynamic many to many model in this app, I am not sure it would work to have a process for every source with n connections.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> <a href="mailto:live-devel-bounces@ns.live555.com">live-devel-bounces@ns.live555.com</a> <a href="mailto:[mailto:live-devel-bounces@ns.live555.com]">[mailto:live-devel-bounces@ns.live555.com]</a> <b>On Behalf Of </b>Ross Finlayson<br><b>Sent:</b> Saturday, November 19, 2011 2:11 AM<br><b>To:</b> LIVE555 Streaming Media - development & use<br><b>Subject:</b> Re: [Live-devel] Access violation crash in rtspclient<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoNormal>The bye handler calls code resulting in Medium::Close. This ends up calling the destructor on the RTCP class and deletes the fKnowMembers.<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Yes.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><div><p class=MsoNormal>The OnReceive is then attempted to be called<o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>No, that shouldn't be happening, because the "RTCPInstance" destructor called "stopNetworkReading()", which stops any further handling of incoming RTCP packets.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I think you're on a 'wild goose chase' here. Because the problem in your application seems to be caused by your 'BYE handler' routine, then why don't you tell us what that routine is doing (or trying to do)?<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal><span class=apple-style-span>Ross Finlayson</span><br><span class=apple-style-span>Live Networks, Inc.</span><br><span class=apple-style-span><a href="http://www.live555.com/">http://www.live555.com/</a></span> <o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></body></html>