On 09/04/15 05:10, Alex Balashov wrote:
Based on the fact that I have seen no further crashes or deadlocks, I would be inclined to rule this campaign a success.
A proof the new embedded systemd supervising the internal eco-system is worth it ;-)
Anyhow, thanks for testing and troubleshooting, it is good to know it was fixed.
Cheers, Daniel
On 03/30/2015 11:07 AM, Daniel-Constantin Mierla wrote:
Very unlikely, that commit restored something that used to be in older version.
On the other hand, I remembered about the report done by Jason that a CANCEL can end up in some very particular cases in a double lock over the reply mutex. In your traces sent to me, it was about some cancel handling, so could be that case. It created a crash because before the commit 0ee3dc, accessing the branch was rather invalid, then went through that code and ended up in the lock.
I already pushed a patch for it: 3957db5fb51e23535a89b15c8f05463e5702424d
Maybe you can backport and report the results. It will be part of the upcoming minor release later this week.
Cheers, Daniel
On 27/03/15 19:11, Alex Balashov wrote:
Daniel,
Is there anything in master:0ee3dc5e3edc49cf62f97ddd87a40b12c59b73ff that might cause this kind of deadlock? I am wondering because I still have the intuitive sense that all the problems I am experiencing with Kamailio 4.2 here are caused in some way by my switch to asynchronous call processing.
I don't have any proof that this deadlock is also an extension of that general problem domain. I just have that feeling, because the Kamailio upgrade corresponded to a config upgrade where the major change made was precisely that.
-- Alex