27 Aug
2015
27 Aug
'15
4:48 p.m.
No, it is triggered by getting the $ci, but it doesn't get further than
parsing the headers for searching the Call-ID.
I just pushed a patch in master branch with some safety operations in
this particular case. Still not clear why it happened, this patch is
just trying to recover, rather than crash. Ultimately, it can still
crash if the memory is completely corrupted -- not the case of your
report where the mem chunk structure is ok.
Updated a testbed with the patch to see how it goes, going to backport
as well after a while.
Cheers,
Daniel
On 26/08/15 20:34, Alex Balashov wrote:
Daniel,
Thank you very much for the feedback.
My personal - untrained - interpretation of the call stack in the core
dump suggests that this was probably the outcome of an attempt to pull
a nonexistent or somehow corrupt PV and add it to the mqueue. Does
that seem reasonable? My config does in fact do this. It does
something like:
route[CDR_EVENT_FAIL] {
$var(qnum) = core_hash("$ci", "", 2);
mq_add("cdr_write$var(qnum)",
"FAIL:$(ci{s.encode.base64}):$TV(Sn)",
"sip_code:$(rs{s.encode.base64});"
"sip_reason:$(rr{s.encode.base64})");
}
-- Alex
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com