[Live-devel] Re-connection handling

[Chris Richardson (WTI)]

Hi,

 

The exceptions you are seeing are almost certainly the result of heap
corruption in your code, which is going to become quickly off-topic for this
list.  However to get you started on fixing this problem:

 

The heap is being validated during the CRT heap calls in debug mode, which
explains why you see the exception happening with different call stacks.
One way to help diagnose heap corruption is to place "assert(
_CrtCheckMemory() );" in various places where you think the corruption may
be occurring.  That will force a heap validation in a known location, rather
than just relying on the CRT debug heap functions to perform the validation
whenever they happen to be called.

 

Chris Richardson

WTI

 

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Erlandsson, Claes P
(CERLANDS)
Sent: Friday, September 14, 2012 11:55 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Re-connection handling

 

There is one case where it doesn't work though, and I'm not sure how to
handle it. This is if I do a seek while the stream is disconnected, then it
never reconnects. In some cases I play a 10s loop where a timer do a seek
every 10s and jumps back (using absolute seeking). Those streams never
reconnect after a disconnection.

 

 

OK, so unless you can tell me a reliable way to reproduce this problem
(perhaps using "openRTSP), then you'll need to figure out yourself why the
LIVE555 library's connection reestablishment code is not working in this
case (and then I'll try to fix it).  Remember, You Have Complete Source
Code.

 

The place to look in the code is near the start of
"RTSPClient::sendRequest()" (line 535 of "liveMedia/RTSPClient.cpp").  When
you do your 'seek' (really "PLAY") operation (that's failing), then is
"fInputSocketNum" <0?  If so, then what value does "openConnection()"
return.

 

If, however, "fInputSocketNum" is >= 0 (in practice, it will be >0), then we
will (eventually) call "send()" (at line 787) to transmit the command.  Is
this "send()" call succeeding, or not?

 

 

 

I've finally come around to try to dig deeper into this reconnect issue.
First, I'd like to point out that I've updated to the latest liveMedia code
(2012.09.13) and I've redesigned my program to only access/create liveMedia
objects/functions within a function triggered by triggerEvent().

 

I put some debug messages in RTSPClient::sendRequest(), but it doesn't seem
to end up there when I do the seek. I do get an exception at random
locations. Sometimes it happens without me doing anything, i.e. directly
when the connection has been re-established, other times the exception
occurs after I try to do something to the RTSP stream, e.g. stop or seek.

 

Below is an example of the call stack for an exception:

...

msvcr90d.dll!_free_base(void * pBlock=0x61d4d496)

msvcr90d.dll!_unlock(int locknum=4)

msvcr90d.dll!operator delete(void * pUserData=0x06a2acf0)

msvcr90d.dll!operator delete(void * pUserData=0x06a2acf0)

msvcr90d.dll!_free_base(void * pBlock=0x05051718)

msvcr90d.dll!strerror(int errnum=111825400)

RtspVideo.dll!BasicUsageEnvironment0::setResultErrMsg()

RtspVideo.dll!readsocket()

RtspVideo.dll!RTSPClient::incomingDataHandler()

RtspVideo.dll!BasicTaskScheduler::SingleStep()

RtspVideo.dll!BasicTaskScheduler0::doEventLoop()

...

 

here is another one:

...

msvcr90d.dll!malloc(unsigned int size=21)

msvcr90d.dll!operator new(unsigned int size=21)

RtspVideo.dll!BasicTaskScheduler::SingleStep()

RtspVideo.dll!BasicTaskScheduler0::doEventLoop()

...

 

Please let me know what I can do to help. I'll continue to look in to this.

 

 

Again, what I do is:

1. Play an archive (i.e. non-live) stream.

2. Unplug Ethernet cable.

3. Do a seek while disconnected.

4. Plug in Ethernet cable.

 

I get an exception every time, but as mentioned above, it appears slightly
different and the call stack usually looks different each time.

 

 

/Claes

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120914/54f64094/attachment.html>