Hi Hugo,
The STUN tdata timer in STUN session (i.e: tdata->res_timer) is scheduled using 'pj_stun_session' group lock, so normally it should be safe from race condition between 'pj_stun_session' destroy and 'on_cache_timeout', but perhaps there is a corner case, could you also send the call stack traces when the crash occurs?
BR,
nanang
On Sat, Jun 29, 2019 at 1:30 AM Hugo Sobral <hugo.sobral@xxxxxxxxx> wrote:
Hi,_______________________________________________Sometimes I get a crash in "pj_timer_heap_poll"I notice that there was some corrections about that in milestone 2.9But these corrections does not solve my issue.After some time debugging the issue, it looks like that it happens when the code:-------------------------------if (node->cb)
(*node->cb)(ht, node);-------------------------------in function 'pj_timer_heap_poll' is invoked with the function 'on_cache_timeout' at the same time that 'pj_stun_session' is being destroyed (this destroy is made by application's code because the call terminates).I cannot understand exactly how this happens,but I think that there is a time gap in function 'pj_timer_heap_poll' after the 'unlock_timer_heap(ht)' that 'pj_stun_session' can be destroyed and crash inside 'on_cache_timeout'Is this a known issue in the specified functions?Best regards,Hugo Sobral
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@xxxxxxxxxxxxxxx
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
_______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip@xxxxxxxxxxxxxxx http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
