Summary:ASTERISK-04604: [patch] app_forkcdr.c bug fix
Reporter:John Riordan (john)Labels:
Date Opened:2005-07-16 00:47:41Date Closed:2008-01-15 15:42:40.000-0600
Versions:Frequency of
Environment:Attachments:( 0) forkcdr_patch.diff
Description:ForkCDR doesn't set cdr->next correctly if called more than once per call.

For example, the second time ForkCDR is called a third cdr is appended to the cdr list with its cdr->next pointing to the second cdr in the list (it should point to NULL as it is now the last in the list). This happens be cause it always copies the first cdr in the list instead of the last and uses whatever cdr->next value is in the first cdr as its cdr->next. The channel then locks up for some reason I didn't track down. If a cli show channel is done on the locked channel, a listing of the cdr variables is attempted and ast_cdr_serialize_variables() goes into an infinate loop following the bad cdr->next pointer (dumping ERROR messages into the log all the while).


The patch rewrites ForkCDR using of functions in cdr.c.

The existing implementation calls ast_cdr_alloc() without checking to see if the malloc was successful and then does a memcpy, a memset on the cdr struct, and makes a call to ast_cdr_copy_vars() to copy an existing cdr. But this seemed better done by simply calling ast_cdr_dup() which does all this safely. Simlarly, ast_cdr_reset() seems like a better choice to reset the new cdr than doing it directly.

The functionality of ForkCDR is not changed by the patch.
Comments:By: Kevin P. Fleming (kpfleming) 2005-07-25 18:49:48

Committed to CVS HEAD, thanks!

By: Brian West (bkw918) 2005-07-25 21:01:27

At the time forkcdr was written ast_cdr_dup didn't exist.


By: Digium Subversion (svnbot) 2008-01-15 15:42:40.000-0600

Repository: asterisk
Revision: 6213

U   trunk/apps/app_forkcdr.c
U   trunk/cdr.c
U   trunk/include/asterisk/cdr.h

r6213 | kpfleming | 2008-01-15 15:42:40 -0600 (Tue, 15 Jan 2008) | 2 lines

use CDR API calls instead of re-implementing them (bug ASTERISK-4604)