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 _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
