|
pjsip: We are using version 2.5.5 on linux and have run into a major problem with pjmedia. When we call pjmedia_master_port_destroy(), it, in turn, calls pjmedia_clock_destroy(). This is core-dumping on linux when glibc (we have a newer version compatible with gcc 6.1.0) tries to free the thread record that is stored in thread-local
storage. The problem is that the thread record was allocated using pj_pool_zalloc() in pj_thread_create() (in os_core_unix.c). Unfortunately, glibc tries to free this memory using free() – in __nptl_deallocate_tsd, it core dumps because the memory address
it is trying to free is not the memory address allocated by malloc(). Instead, it is offset by a linked-list pointer that is used internally by pj_pool_zalloc(). When it core dumps, you get an error message complaining that memory has been double-freed or
corrupted. Neither is really the case, just the memory address passed to free is not what was allocated in malloc(). We created a kludge to fix this by simple using malloc() instead of pj_pool_zalloc(). Unfortunately, there are other race condition problems in pjmedia_clock_destroy(). In that file, it sets clock->quitting = PJ_TRUE. It then uses the pointer in thread-local storage for pj_thread_join() and pj_thread_destroy(). However,
if you lose control of the CPU, the clock thread may actually end, its TLS be destroyed, and you will be accessing memory that has been freed. To get around this, you’ll need to make a copy of the thread record locally and use the local copy after setting
clock->quitting to true. Thanks. David Ward Thales |
_______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip@xxxxxxxxxxxxxxx http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
