Hi Alex,
Yes, we consider the possibility and we think it should be safe because:
- The lock is released only for timer timeout event (it's still held for other scenarios).
- When that happens:
1. The tsx state just switches to TERMINATED or DESTROYED.
2. There should be no other processing taking place. All other events, such as the ones handled by tsx_on_state_terminated() should be ignored.
3. tsx_shutdown(), which will destroy the transaction, hasn't been called (because it's only called at the end of tsx_set_state() and because of 2).
We could still miss something in our analysis, though.
Best regards,
Ming
On Mon, Mar 20, 2017 at 11:05 PM, Alex Hermann <alex-lists@xxxxxxxxx> wrote:
On maandag 20 maart 2017 18:44:58 CET Ming wrote:
> As promised, attached is the patch which should fix the issue. Please let
> us know your test result and if you have any feedback. Thanks.
Thanks for looking into this and providing the patch.
All i can say for now is that the patch applies, the code compiles and an
Asterisk server using the freshly compiled lib is handling calls. The deadlock
is very hard to trigger, so I can probably never report if the problem still
exists or is fully resolved.
One question on the patch though:
I'm not very familiar with the pjproject code, but the patch looks suspicious
to me. The tsx group lock is now temporarily released, but wasn't it locked
for a reason?
Can't the tsx object get freed directly after unlocking, possibly resulting in
a segfault when (*tsx->tsx_user->on_tsx_state)(tsx, &e); is called?
--
Alex Hermann
_______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip@xxxxxxxxxxxxxxx http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
