> - from the core dumps it's hard to tell which action causes the crash since > it's an asynchronous event but the stack trace is always the same: > « > (gdb) bt > #0 0x636e456c in ?? () > #1 0x08091c89 in FramedSource::afterGetting (source=0x8647d50) at > FramedSource.cpp:91 > #2 0x080d8825 in AlarmHandler::handleTimeout (this=0x85d74b8) at > BasicTaskScheduler0.cpp:34
This suggests that the problem might be that a LIVE555 source object (i.e., of a “FramedSource” subclass) is somehow being deleted while it’s in the process of being ‘played’ (i.e., streamed from). I suggest looking at the various places - within your own application code - where you might be deleting LIVE555 objects (using “Medium::close()”), and make sure that you’re not accidentally deleting them twice, or not deleting them when the LIVE555 library code deletes them as well. (Note that, for example, if you have a ‘chain’ of source objects: A->B->C (i.e., with B and C being “FramedFilter” subclasses), then only object C should be deleted explictly; the LIVE555 code will automatically delete B and A for you.) Another thing I suggest is running your code under “valgrind”. If - as I suspect - the code is trying to access an object that has recently been deleted, then “valgrind” may be able to tell you specifically where in the code the object was deleted. Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
