[Live-devel] Access violation crash in rtspclient

[Jeff Shanab]

After tracing through there seems to be, dare I say a bug or misleading testProgram.

The bye handler calls code resulting in Medium::Close. This ends up calling the destructor on the RTCP class and deletes the fKnowMembers.
The OnReceive is then attempted to be called where it ends up trying to use that now deleted pointer.

It looks like The playCommon.cpp gets around the ensueing access violation by calling exit()  Something I cannot do.

Is this analysis correct? Or did I somehow confuse some pointers to sessions/subsessions.

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.


From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Jeff Shanab
Sent: Friday, November 18, 2011 11:04 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Access violation crash in rtspclient

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.

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!

From: live-devel-bounces at ns.live555.com<mailto:live-devel-bounces at ns.live555.com> [mailto:live-devel-bounces at ns.live555.com]<mailto:[mailto:live-devel-bounces at ns.live555.com]> On Behalf Of Ross Finlayson
Sent: Wednesday, November 16, 2011 6:15 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Access violation crash in rtspclient

While waiting for a reply I updated to 11/8/2011. The problem is exactly the same.
I am however still using the async interface, the re-write would kill me right now.

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.

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.

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?

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

________________________________
No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2012.0.1869 / Virus Database: 2092/4620 - Release Date: 11/16/11
________________________________
No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2012.0.1872 / Virus Database: 2092/4624 - Release Date: 11/18/11
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20111118/cc9d4af8/attachment.html>