[Home]

Summary:ASTERISK-04415: [patch] ResetCDR causes deadlock and/or segfault.
Reporter:Anthony Minessale (anthm)Labels:
Date Opened:2005-06-15 01:16:12Date Closed:2011-06-07 14:03:01
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) reset_cdr_fix.diff
Description:This patch fixes an issue in ast_cdr_reset where a cdr record is duplicated with memcpy but the varshead is not tended to properly causing a crash or deadlock.  The static function ast_cdr_dup is added to the module to wrap the work of cloning a cdr record and is then used in the ast_cdr_reset.



****** ADDITIONAL INFORMATION ******

Disclaimer on file
anthmct@yahoo.com
Comments:By: Clod Patry (junky) 2005-06-15 10:04:42

Before that patch, i had:
asterisk*CLI> cdr status
CDR logging: enabled
CDR mode: batch
CDR safe shut down: enabled
CDR batch threading model: scheduler plus separate threads
CDR current batch size: 1 record(s)
CDR maximum batch size: 50 record(s)
CDR maximum batch time: 60 second(s)
CDR next scheduled batch processing time: 48 second(s)
CDR registered backend: pgsql
CDR registered backend: csv
CDR registered backend: cdr_manager
asterisk*CLI> cdr submit
asterisk*CLI> cdr st<tab>
and there's nothing, it's frozen. I need to ctrl-c and asterisk -r again.


And with that patch:
asterisk*CLI> cdr status
CDR logging: enabled
CDR mode: batch
CDR safe shut down: enabled
CDR batch threading model: scheduler plus separate threads
CDR current batch size: 1 record(s)
CDR maximum batch size: 50 record(s)
CDR maximum batch time: 60 second(s)
CDR next scheduled batch processing time: 38 second(s)
CDR registered backend: csv
CDR registered backend: pgsql
CDR registered backend: cdr_manager
CDR registered backend: cdr-custom
asterisk*CLI> cdr submit
Submitted CDRs to backend engines for processing.  This may take a while.
Jun 15 11:01:40 DEBUG[18348]: cdr_pgsql.c:100 pgsql_log: cdr_pgsql: inserting a CDR record.
Jun 15 11:01:40 DEBUG[18348]: cdr_pgsql.c:108 pgsql_log: cdr_pgsql: SQL command executed:  INSERT INTO cdr (calldate,clid,src,dst,dcontext,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,accountcode,uniqueid,userfield) VALUES ('2005-06-15 11:01:27','"Clod Patry" <154>','154','100','test_sip', 'SIP/154-5478','SIP/100-8e1d','Dial','SIP/100',4,3,'ANSWERED',3,'','1118847687.0','')
asterisk*CLI>

And it seems to work even when current batch size is 0:
asterisk*CLI> cdr submit
Submitted CDRs to backend engines for processing.  This may take a while.
asterisk*CLI>
By: damin (damin) 2005-06-16 16:35:54

I was just testing a CVS Head box and was bitten by this bug. This is NASTY! Please allow this note to serve as a request to get this applied ASAP!
By: Mark Spencer (markster) 2005-06-16 20:34:46

Fixed in head.
By: Anthony Minessale (anthm) 2005-06-16 23:02:34

ahem, karma?, finding and fixing a non-trivial bug that is not yours?
/me paces looking at the 197 at the top of the page.
By: Michael Jerris (mikej) 2005-06-17 09:01:48

As for stable, this issue was caused by the cdr batching stuff that got added to head only.  Is this possibly an issue in stable?
By: Digium Subversion (svnbot) 2008-01-15 15:38:20.000-0600

Repository: asterisk
Revision: 5920

U   trunk/cdr.c

------------------------------------------------------------------------
r5920 | markster | 2008-01-15 15:38:19 -0600 (Tue, 15 Jan 2008) | 2 lines

Fix reset cdr (bug ASTERISK-4415)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=5920