[Live-devel] Unhandled exception during TEARDOWN

Erlandsson, Claes P (CERLANDS) CERLANDS at arinc.com
Thu Jan 10 19:42:14 PST 2013


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.

 

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.

 

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

 

 

Thanks a lot for taking the time to test it.

 

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.

 

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

 

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. 

 

 

/Claes

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130111/404520b0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5740 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130111/404520b0/attachment.bin>


More information about the live-devel mailing list