<div dir="ltr">Hi,<div><br></div><div>I captured a segfault (sadly without a core) on a customer site as follows:</div><div><br></div><div>asterisk[16862]: segfault at 770 ip 08098fa0 sp b483bdc0 error 4 in asterisk[8048000+18f000]</div>
<div><br></div><div><div># addr2line -e asterisk 08098fa0</div><div>/usr/src/asterisk-1.8.26.0/main/cdr.c:741</div></div><div><br></div><div><div>740:        for (; cdr; cdr = cdr->next) {</div><div>741:               if (ast_test_flag(cdr, AST_CDR_FLAG_ANSLOCKED))</div>
<div>742:                        continue;</div></div><div><br></div><div>The only way I can see that line causing a segv is if another thread were destroying or detaching the channel's CDR at the same time as the cdr_answer was occurring. There are a few places where CDR operations like 'ast_cdr_answer(chan->cdr)' are called without the channel being locked.<br>
</div><div><br></div><div>Having looked up all references to ast_cdr_answer(), ast_cdr_discard() and ast_cdr_detach(), my favourite combination for causing this is simultaneous execution of:</div><div>        channel.c: ast_hangup(chan)<br>
</div><div>and</div><div>        channel.c: ast_raw_answer(chan) called on a channel that is already AST_STATE_UP.</div><div><br></div><div>I will attempt to reproduce this and grab a backtrace, but any clues or suggestions will be welcome.</div>
<div><br></div><div>Regards,</div><div>Steve</div></div>