[asterisk-users] Channel name in queue log replaced by a manager event?

[James FitzGibbon]

Under 1.4.5 and 1.4.6, I've seen a few instances where the channel name in
queue log entries is replaced by a snippet of a manager event:

--START--
1183582823|1183582823.104763|queuename|SIP/XXXX|REMOVEMEMBER|
1183582828|1183582793.104744|queuename|
Context: macro-dialout
Extension: s
Priority: 3
Application: GotoIf
AppData: 0?blockclid
Uniqueid: 1183582822.104759

|CONNECT|12|1183582816.104754
1183582833|1183582485.104605|queuename|SIP/XXXX|AGENTATTEMPT|
---END---

--START--
1183762515|1183762515.18034|queuename|SIP/XXXX|REMOVEMEMBER|
1183762518|1183762485.18025|queuename|
Context: from-somecontext
Extension: XXXX
Priority: 6
Application: Hangup
AppData:
Uniqueid: 1183762515.18034

|CONNECT|5|1183762513.18033
---END---

--START--
1183762659|1183762631.18061|queuename|NONE|EXITWITHTIMEOUT|1
1183762661|1183762485.18025|queuename|: macro-singlequeue
Extension: s-TIMEOUT
Priority: 1
Application: VoiceMail
AppData: XX|uj
Uniqueid: 1183762631.18061

|COMPLETEAGENT|5|143|1
1183762665|1183762211.17926|queuename|SIP/XXXX|RINGNOANSWER|20000
---END---

Because the text snippet that replaces the channel name always contains
newlines, this makes my queue stats program (QueueMetrics) go crazy.  The
first part of the line is incomplete, and the second is invalid.  If the
CONNECT event is what gets lost, then the display shows the call as waiting
in queue forever.  In every case, it's been the channel name that gets
replaced, no other field in the queue log lines.

I'm assuming it's some pointer badness going on, but I'm not sure what I'll
be able to provide beyond this and a basic config snippet to help track it
down - I can't reproduce it on demand, and replicating the conditions under
which I've observed it requires four PRIs worth of traffic.

It does seem that once a given call has it's channel name pointer corrupted,
it remains corrupted until the end of the call - I've never seen a
ENTERQUEUE with a proper channel name followed by a corrupted CONNECT then a
good COMPLETECALLER.  So far, the corruption has first appeared when the
CONNECT event is logged.


Any thoughts, or should I just replicate what I've got into the bugtracker?

Thanks

-- 
j.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20070706/360b1602/attachment.htm