<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 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 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;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:black;}
.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 style='margin-left:.5in'>I ran your modified application for several hours (on FreeBSD, under GDB), and also on Linux using "valgrind", but unfortunately was unable to find any problem.<o:p></o:p></p><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>I suspect that whatever bug is causing this is something that (for some reason) is causing an exception only in your environment. I'm still interested in learning the cause, of course (especially if it is - as it appears to be - a bug in our code), but it looks like you're probably going to have to track this down yourself.<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:.5in'><span class=apple-style-span><span style='font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black'>Ross Finlayson</span></span><span style='font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black'><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></span> <o:p></o:p></p></div><p class=MsoNormal style='margin-left:.5in'><span style='color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Courier New";color:black'>Thanks a lot for taking the time to test it.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Courier New";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Courier New";color:black'>I'm not really sure how to proceed, but I guess I can try to locate a Linux client to compile and run the test on. It can of course be the Cisco server that does something that somehow triggers the issue to occur in the client. Cisco VSM7 should however be a complete rewrite from VSM6 and since the behavior in this case is exactly the same it would surprise me a bit, but any "oddities" can of course be carried over to a new version, rewrite or not. I've however never seen anything strange in the logs indicating this.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Courier New";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Courier New";color:black'>As already mentioned, the issue always happens after calling sendTeardownCommand() (with a response handler). When looking at the callstack after the unhandled exception I often see slightly different locations, where the last reference point is to some system DLL, e.g. ntdll or msvcr90d.dll. The last RTSP client function call in the callstack is often BasicTaskScheduler::SingleStep(). Would it be of any help to keep track of and pass on the callstacks (or any other info)?<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Courier New";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Courier New";color:black'>As expected, the debug output (from the previously attached test program) always ends with the line "Opening connection to 192.168.1.103, port 554..." after a TEARDOWN request has been sent. I've attached an output example; not sure if it might be of any help. It can be seen that the TEARDOWN response often comes after the new stream has been started, but I assume that is ok. <o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Courier New";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Courier New";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Courier New";color:black'>/Claes<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p></div></body></html>