[asterisk-bugs] [JIRA] (ASTERISK-27977) Crash at T38 call disconnection

Asterisk Team (JIRA) noreply at issues.asterisk.org
Thu Jul 19 15:23:54 CDT 2018


     [ https://issues.asterisk.org/jira/browse/ASTERISK-27977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Asterisk Team closed ASTERISK-27977.
------------------------------------


> Crash at T38 call disconnection
> -------------------------------
>
>                 Key: ASTERISK-27977
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27977
>             Project: Asterisk
>          Issue Type: Information Request
>      Security Level: None
>          Components: Resources/res_pjsip_t38
>    Affects Versions: 13.20.0
>            Reporter: Salah Ahmed
>            Severity: Minor
>
> Hello,
> I am very new in this asterisk world, please pardon me if it wrong request. 
> Actually I am very confused during a study of a core dump, thats why I am requesting here to get some help. 
> Scenario:
> This core was happened after a T38 successful call. I assumed it happened due to udptl packet read after call disconnection.
> Back trace full,
> ===================
>   #0  0x000000000045dd5f in internal_ao2_traverse (self=0x7fae7063ecc0, flags=flags at entry=OBJ_SEARCH_KEY, 
>     cb_fn=<optimized out>, arg=arg at entry=0x7fb08a396360, tag=tag at entry=0x0, file=file at entry=0x0, 
>     line=0, func=0x0, type=AO2_CALLBACK_DEFAULT, data=0x0) at astobj2_container.c:354
>         match = 3
>         ret = 0x0
>         cb_default = 0x7fb11ad88dc0 <session_media_cmp>
>         node = 0x4
>         traversal_state = 0x7fadffeaaa60
>         orig_lock = AO2_LOCK_REQ_MUTEX
>         multi_container = 0x0
>         multi_iterator = 0x0
> #1  0x000000000045e6f3 in __ao2_callback (arg=0x7fb08a396360, cb_fn=<optimized out>, 
>     flags=OBJ_SEARCH_KEY, c=<optimized out>) at astobj2_container.c:455
> No locals.
> #2  __ao2_find (c=<optimized out>, arg=arg at entry=0x7fb08a396360, flags=flags at entry=OBJ_SEARCH_KEY)
>     at astobj2_container.c:496
>         arged = 0x7fb08a396360
> #3  0x00007fb08a393aec in t38_framehook_read (session=0x7fae722a2ad0, session=0x7fae722a2ad0, f=0x0, 
>     chan=0x7fae73b24150) at res_pjsip_t38.c:448
>         session_media = <optimized out>
> #4  t38_framehook (chan=0x7fae73b24150, f=0x0, event=<optimized out>, data=<optimized out>)
>     at res_pjsip_t38.c:466
>         channel = <optimized out>
> #5  0x000000000051cc2b in framehook_list_push_event (framehooks=0x7fae711f6f50, frame=0x0, 
>     event=AST_FRAMEHOOK_EVENT_READ) at framehook.c:118
>         __list_head = 0x7fae711f6f58
>         __list_next = 0x0
>         __list_prev = <optimized out>
>         __list_current = 0x7fae70016be0
>         num = 0
>         framehook = 0x7fae70016be0
>         original_frame = 0x0
>         skip = 0x7fadffeaabe0
>         skip_size = <optimized out>
> #6  0x00000000004bdd45 in __ast_read (chan=0x7fae73b24150, dropaudio=0) at channel.c:3973
>         cause = 0
>         __PRETTY_FUNCTION__ = "__ast_read"
> #7  0x00000000004827c6 in bridge_handle_trip (bridge_channel=<optimized out>) at bridge_channel.c:2416
>         frame = 0x0
> #8  bridge_channel_wait (bridge_channel=<optimized out>) at bridge_channel.c:2586
>         ms = -1
>         outfd = -99999
>         chan = 0x7fae73b24150
> #9  bridge_channel_internal_join (bridge_channel=0x7fae70e8a560) at bridge_channel.c:2732
>         res = 0
>         channel_features = 0x0
>         swap = 0x7fae70e8a630
>         __PRETTY_FUNCTION__ = "bridge_channel_internal_join"
> #10 0x000000000046c600 in bridge_channel_ind_thread (data=data at entry=0x7fae70e8a560) at bridge.c:1782
>         bridge_channel = 0x7fae70e8a560
>         chan = <optimized out>
>         __PRETTY_FUNCTION__ = "bridge_channel_ind_thread"
> #11 0x00000000005e6dfa in dummy_start (data=<optimized out>) at utils.c:1238
>         __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {140387192380000, -7728970672055937793, 
>                 0, 140387183878800, 19, 140385299642112, 7775132476379337983, -7728970105745206017}, 
>               __mask_was_saved = 0}}, __pad = {0x7fadffeaaef0, 0x0, 
>             0x7fb13a9d4812 <__libc_thread_freeres+34>, 0x7fae7039e290}}
>         __cancel_arg = 0x7fadffeab700
>         __not_first_call = <optimized out>
>         ret = <optimized out>
>         a = {start_routine = 0x46c5e0 <bridge_channel_ind_thread>, data = 0x7fae70e8a560, 
>           name = 0x7fae70bb9a60 "bridge_channel_ind_thread started at [ 1874] bridge.c bridge_impart_internal()"}
> #12 0x00007fb13b688064 in start_thread (arg=0x7fadffeab700) at pthread_create.c:309
>         __res = <optimized out>
>         pd = 0x7fadffeab700
>         now = <optimized out>
>         unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140385299642112, -7728970672055937793, 0, 
>                 140387183878800, 19, 140385299642112, 7775132476400309503, 7773029126418175231}, 
>               mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, 
>               cleanup = 0x0, canceltype = 0}}}
>         not_first_call = <optimized out>
>         pagesize_m1 = <optimized out>
>         sp = <optimized out>
>         freesize = <optimized out>
>         __PRETTY_FUNCTION__ = "start_thread"
> #13 0x00007fb13a97062d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> ===================
> My confusions are,
> 1. In frame 3 session->media is NULL and in frame 1 __ao2_find method has a null check on c, then how its proceed further?
> In Frame 3
> (gdb) p session->media
> $20 = (struct ao2_container *) 0x0
> 2. t38_framehook_read method takes 3 args but in frame 3 we have found in gdb it takes 4 value. how this is happen? Is this core file corrupted somehow?
> 3. Please advice me some idea how can I move forward on this core dump.
> Please let me know if you need any info on it. 
> Thanks,
> Rubel
>   



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



More information about the asterisk-bugs mailing list