[asterisk-bugs] [JIRA] (ASTERISK-25426) Core dump in CDR handler

[Morten Tryfoss (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-25426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=227790#comment-227790 ] 

Morten Tryfoss commented on ASTERISK-25426:
-------------------------------------------

I had a log of all executed AGI-commands, but unfortunately some cron job did as it was supposed to.. I'm trying to reproduce it again now (with asterisk debug as well).

But in general the script is executed on a two-way originate from asterisk. When the AGI manages to get answered by an agent, it will call the customer on the other leg.
The AGI is a big while(true) which dials local channels to different end points/agents (either mobile through a sip trunk or a local sip phone). 

The agents had not logged out after work and the queue was not emptied as it should so this had been doing a little over 4000 attempts before it crashed. That would be a really large CDR, I guess! 

After what i remember from the log, there was a little mix of hangup causes generated from the different phones.
 

> Core dump in CDR handler
> ------------------------
>
>                 Key: ASTERISK-25426
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25426
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: CDR/General
>    Affects Versions: 13.5.0
>         Environment: Centos 6.6, x86_64
>            Reporter: Morten Tryfoss
>            Assignee: Morten Tryfoss
>         Attachments: backtrace.txt
>
>
> We have a custom developed queue solution. This also have a callback-module which tries to originate a two-way call between an agent on the callcenter and the customer. For this specific case the call was not answered by the agent before the callcenter closed, and the agent did not log out of the queue so the system continued to try to deliver the call through the night.
> I think this led to a build up of cdr variables and at some point, it crashes.
> Partial output from gdb:
> {noformat}
> #6919 0x000000000045c759 in __ao2_ref (user_data=0x7feb94050ed8, delta=-1) at astobj2.c:516
> #6920 0x000000000045c7d4 in __ao2_cleanup (obj=0x7feb94050ed8) at astobj2.c:529
> #6921 0x000000000049d10e in _dtor_cdr (v=0x7febd12d0af8) at cdr.c:2070
> #6922 0x000000000049d4cc in handle_channel_cache_message (data=0x0, sub=0x1cf68e8, message=0x7feac4d950a8) at cdr.c:2070
> #6923 0x00000000005d3cc0 in router_dispatch (data=0x1cf21f8, sub=0x1cf68e8, message=0x7feac4d950a8) at stasis_message_router.c:201
> #6924 0x00000000005c3359 in subscription_invoke (sub=0x1cf68e8, message=0x7feac4d950a8) at stasis.c:433
> #6925 0x00000000005c3eaf in dispatch_exec_async (local=0x7febd12d0c40) at stasis.c:695
> #6926 0x00000000005de2e4 in ast_taskprocessor_execute (tps=0x1cf6608) at taskprocessor.c:766
> #6927 0x00000000005dca7f in default_tps_processing_function (data=0x1cf6548) at taskprocessor.c:184
> #6928 0x00000000005f20d4 in dummy_start (data=0x1cf6870) at utils.c:1237
> #6929 0x000000385f2079d1 in start_thread () from /lib64/libpthread.so.0
> #6930 0x000000385eee88fd in clone () from /lib64/libc.so.6
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)