[Live-devel] Access violation crash in rtspclient

[Jeff Shanab]

2 adjustments to the library allow me to tiptoe thru the call stack avoiding accessing destroyed or already deleted members and unwind this stack.

I do not suggest these at all, they are a hack, but it confirms for me what is happening with the call stack.

Add an exit label with a dummy command at the end of the while loop beyond the onReceive call to avoid it.
First modify RTCP.cpp
....
    onReceive(typeOfPacket, totPacketSize, reportSenderSSRC);
    exit:
        int dummy = 0;
  } while (0);

}

Then after calling the bye handler jump to it

                    (*byeHandler)(fByeHandlerClientData);
        goto exit;
                  }

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"
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.
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++.



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

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.
(This issue is avoided in openRTSP by just exiting the process before the access violation could hit.)

It boils down to calling the destructor of a class from a member in the class puts us in undefined territory.

I call your attention to RTCP.cpp from 11/08/2011

In the switch statement in incomingReportHandler1 at line 511, we handle the case of an incoming "BYE" message.
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.
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.
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.

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.

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: Saturday, November 19, 2011 2:11 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Access violation crash in rtspclient

The bye handler calls code resulting in Medium::Close. This ends up calling the destructor on the RTCP class and deletes the fKnowMembers.

Yes.


The OnReceive is then attempted to be called

No, that shouldn't be happening, because the "RTCPInstance" destructor called "stopNetworkReading()", which stops any further handling of incoming RTCP packets.

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)?

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20111119/16f5df18/attachment.html>