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