[asterisk-dev] [Code Review] 2983: app_queue: crash if first agent is "busy"

[Kevin Harwell]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2983/
-----------------------------------------------------------

Review request for Asterisk Developers, Matt Jordan and Mark Michelson.


Bugs: ASTERISK-22644
    https://issues.asterisk.org/jira/browse/ASTERISK-22644


Repository: Asterisk


Description
-------

If the first agent/member (via CLI "queue show") in a queue is "busy" (dnd, circuit busy, etc...) and no agents answered then app_queue would crash.  This occurred because while the calling of agent(s) remained valid the channel on "busy" agent would be set to NULL and then later dereferenced upon a second "rna" function call.  The original intention of the code is to have only valid "call attempt" objects (channels != NULL) checked while attempting to call agent(s).  It does this by building a "call_next" list of valid "call attempt" objects.  In the case of the "busy" agent subsequent builds of the valid "call attempt" list would sometimes include (the case mentioned above) an invalid "call attempt" object.

The fix was to make sure the "call attempt" list was appropriately built on every iteration.  A NULL sanity check was also added at the original offending spot of the crash just in case another one slipped by somehow.


Diffs
-----

  branches/12/apps/app_queue.c 402326 

Diff: https://reviewboard.asterisk.org/r/2983/diff/


Testing
-------

Recreated the crash by creating a queue with 3 members with the first member's status set to "dnd".  Once the fix was in ran the test again to and made sure Asterisk no longer crashed.  After that I tried various combinations of phones being set to "busy" at various times during agent calling, including none and all three.


Thanks,

Kevin Harwell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131031/5fb5c73f/attachment.html>