[Home]

Summary:ASTERISK-27977: Crash at T38 call disconnection
Reporter:Salah Ahmed (rubel)Labels:
Date Opened:2018-07-19 15:22:13Date Closed:2020-01-14 11:21:09.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:Resources/res_pjsip_t38
Versions:13.20.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description: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@entry=OBJ_SEARCH_KEY,
   cb_fn=<optimized out>, arg=arg@entry=0x7fb08a396360, tag=tag@entry=0x0, file=file@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@entry=0x7fb08a396360, flags=flags@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@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
 
Comments:By: Asterisk Team (asteriskteam) 2018-07-19 15:22:15.818-0500

We appreciate the difficulties you are facing, however information request type issues would be better served in a different forum.

The Asterisk community provides support over IRC, mailing lists, and forums as described at http://asterisk.org/community. The Asterisk issue tracker is used specifically to track issues concerning bugs and documentation errors.

If this issue is actually a bug please use the Bug issue type instead.

Please see the Asterisk Issue Guidelines [1] for instruction on the intended use of the Asterisk issue tracker.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines

By: Asterisk Team (asteriskteam) 2018-07-19 15:22:16.379-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].