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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel