<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/"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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'>After tracing through there seems to be, dare I say a bug or misleading testProgram.<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'>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></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The OnReceive is then attempted to be called where it ends up trying to use that now deleted pointer.<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'>It looks like The playCommon.cpp gets around the ensueing access violation by calling exit() Something I cannot do.<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'>Is this analysis correct? Or did I somehow confuse some pointers to sessions/subsessions.<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'>If so How do I handle the “BYE” message gracefully? If I move the Medium::close to the destructor for my client, then it necessarily hangs on shutdown because there is nothing to change the watchvariable.<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><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> Friday, November 18, 2011 11:04 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>Following your suggestion I got the Bye handlers working better. But I am back to a situation that may indicate I am doing to much in my handler.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The case in incomingReportHandler1 that handles the BYE falls thru to and tries to execute onRecieve with the old data. In on receive it tries to access a now dead class member I guess and throws an access violation. I am trying to search thru the openRTSP example as I discovered the much older openRTSP was the basis for our client (before I got here) But If you have any suggestions on what not to do in the bye handler chain, I would appreciate it!<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> Wednesday, November 16, 2011 6:15 PM<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>While waiting for a reply I updated to 11/8/2011. The problem is exactly the same.<o:p></o:p></p></div><div><p class=MsoNormal>I am however still using the async interface, the re-write would kill me right now.<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Do you mean "still using the *synchronous* interface" (i.e., the old, now-deprecated interface)? But in any case, that's OK; either interface is supposed to be working without error.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>First, I suggest running our "openRTSP" command-line RTSP client to access the server that's causing you problems. If "openRTSP" also crashes for you (with that server), then the job will be easier, because it shows that there's a problem even with our unmodified released code.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If, however, the problem happens only with your client application, then I suggest looking at what happens - in your code - after a RTCP "BYE" arrives from the server. I presume that you have set a 'BYE handler' - using the function "RTCPInstance::setByeHandler()". Do any other of your servers send RTCP "BYE" packets (thereby triggering the calling of your 'BYE handler'), or does only your new, troublesome server send a RTCP "BYE"? If it's only your new server that sends this, then this suggests that there is a problem with your 'BYE handler' (because it had not been called before). Perhaps you are closing/deleting objects in the wrong order, or trying to delete some objects more than once?<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 class=MsoNormal align=center style='text-align:center'><hr size=1 width="100%" noshade style='color:#A0A0A0' align=center></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>No virus found in this message.<br>Checked by AVG - <a href="http://www.avg.com">www.avg.com</a><br>Version: 2012.0.1869 / Virus Database: 2092/4620 - Release Date: 11/16/11<o:p></o:p></p><div class=MsoNormal align=center style='text-align:center'><hr size=1 width="100%" noshade style='color:#A0A0A0' align=center></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>No virus found in this message.<br>Checked by AVG - <a href="http://www.avg.com">www.avg.com</a><br>Version: 2012.0.1872 / Virus Database: 2092/4624 - Release Date: 11/18/11<o:p></o:p></p></div></body></html>