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-boun...@ns.live555.com [mailto:live-devel-boun...@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
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
