Norman Franke wrote: >>> 1. When calls end, the conference port is not automatically released. >>> Why not? After a while, 32 active connects were established and >>> things >> It should. The idea is when a port is removed, all things related to >> this port should have been released. > > It wasn't, but perhaps that's #428. That assert was in conference.c, > sorry. Yeah that was it. But still I don't understand why it triggers assertion in pool.c, so I'm still not 100% convinced that #427 and #428 fixed the original problem. >> pjmedia_port_destroy() doesn't release the pool since it doesn't own >> it, and pool's memory is never freed until the pool itself is >> destroyed, these are by design. I suspect the crash is caused by the >> pool emitting an exception which is not handled by application. >> Although if you said you enabled assertion, you should get assert() >> in pj/except.c instead of a crash (see pj_throw_exception_() >> function). > > That I understand. I should it would release the memory it was using > in the pool, or doesn't it work that way? I never did run out of Nope, we don't have pj_pool_free() to release individual memory alloc'ed from a pool. > memory, it just kept growing and eventually crashed. It looked like > the pool became corrupted somehow. There must be something that upset the pool, since pool doesn't just crash because it contains too much memory (well at least in my tests). Since you said that your allocation from that pool always comes from the same thread, and the pool is not released more than once (this would have been caught with the assertion in pool_caching.c when you enabled PJ_SAFE_POOL), then the only other reason that I could think of would be that something had overwritten the pool and corrupting it. Maybe it was #428, although I'm not so convinced. If you're feeling brave, then you can undo your modification to the way you use the pool and let it grow indefinitely as before, and see if it crashes again. ;-) Or, since I believe there's nothing wrong with the pool, and your program now runs fine anyway, maybe we can just forget about this. ;-) cheers, -benny >>> With these two changes, I haven't had a crash in a day. However, I'm >>> still puzzled why it crashed? I never used the pools in another >>> thread, >>> just to create the ports. >>> >>> I did try PJ_SAFE_POOL earlier and besides slowing the audio down to >>> where it was garbled, I never got an error after a large number of >>> test >>> calls. >> I'm also puzzled. The crash in pool.c that you mentioned before >> seems to suggest that the pool's internal data might have been >> reset, and I thought it may have been caused by the pool being >> released more than once, so PJ_SAFE_POOL should catch this. >> Apparently it didn't, so I'm puzzled. > > > Again, it never did run out of memory. Just crashed while walking the > linked list in the pools. > > So far, no crashes in a few days. > > -Norman > >
