[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=227797#comment-227797 ] 

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

Managed to make asterisk crash again now. Answered the two-way call that has been ringing through the night.

One thing I noticed in the debug log for the call that has been running over about 10-11 hours:
[Oct  7 08:09:05] DEBUG[1625] cdr.c: Finalized CDR for Local/1_morten at ncomqueue-000623c6;2 - start 1444198139.266233 answer 1444198144.500025 end 1444198145.510915 dispo ANSWERED
[Oct  7 08:09:05] DEBUG[1625] cdr.c: Finalized CDR for Local/1_morten at ncomqueue-000623c6;2 - start 1444198145.515189 answer 1444198145.515189 end 1444198145.516975 dispo ANSWERED

While when asterisk doesn't crash:
[Oct  7 08:26:38] DEBUG[14737] cdr.c: Finalized CDR for Local/1_morten at ncomqueue-00000049;2 - start 1444199191.033973 answer 1444199194.872059 end 1444199198.514642 dispo ANSWERED
[Oct  7 08:26:38] DEBUG[14737] cdr.c: Finalized CDR for Local/1_morten at ncomqueue-00000049;2 - start 1444199198.517425 answer 1444199198.517426 end 1444199198.518279 dispo ANSWERED
[Oct  7 08:26:38] DEBUG[14737] cdr.c: Finalized CDR for Local/1_morten at ncomqueue-00000049;1 - start 1444199194.872478 answer 1444199194.872112 end 1444199198.518948 dispo ANSWERED

The CDR for the local channel ending with ";1" is not written.
This particular channel is the one involved directly in the two-way originate. The CDR data (level XX) is building up on the channel ending with ";2".
All other CDR's involved in the call seems to be written correctly based on a compare of the two logs.

I'm starting to think that this might have something to do with a long running originate instead? Are there any clean up routines running which messes up the CDR?

> 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: Unassigned
>         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)