30 Mar
2015
30 Mar
'15
11:07 a.m.
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
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com