[asterisk-bugs] [JIRA] (ASTERISK-28885) res_rtp_asterisk: Simultaneous termination and ICE complete can cause crash

[Friendly Automation (JIRA)]

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

Friendly Automation commented on ASTERISK-28885:
------------------------------------------------

Change 14450 merged by Friendly Automation:
res_rtp_asterisk: Re-order RTP destruction.

[https://gerrit.asterisk.org/c/asterisk/+/14450|https://gerrit.asterisk.org/c/asterisk/+/14450]

> res_rtp_asterisk: Simultaneous termination and ICE complete can cause crash
> ---------------------------------------------------------------------------
>
>                 Key: ASTERISK-28885
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28885
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 13.32.0
>         Environment: Centos 7.5, Asterisk 13.32.0
>            Reporter: Josep B
>            Assignee: Joshua C. Colp
>            Severity: Minor
>              Labels: fax, webrtc
>         Attachments: core SIGABRT res_rtp_asterisk.zip, endpoint-config.txt
>
>
> Hi,
> We are using asterisk 13.32.0 with pjsip 2.9 bundled, using webrtc transport with ‘rel100‘ activated.
> We get a SIGABRT crash:
> #0  0x00007ff76c375337 in raise () from /usr/lib64/libc.so.6
> #1  0x00007ff76c376a28 in abort () from /usr/lib64/libc.so.6
> #2  0x00007ff76c3b7e87 in __libc_message () from /usr/lib64/libc.so.6
> #3  0x00007ff76c3c0679 in _int_free () from /usr/lib64/libc.so.6
> #4  0x00007ff69acd67e7 in ast_rtp_remote_address_set (instance=<optimized out>, addr=0x7ff68818e320) at res_rtp_asterisk.c:6159
> #5  0x0000000000590655 in rtp_instance_set_incoming_source_address_nolock (address=0x7ff68ce97b80, instance=0x7ff68818e1e8) at rtp_engine.c:549
> #6  ast_rtp_instance_set_requested_target_address (instance=instance at entry=0x7ff68818e1e8, address=address at entry=0x7ff68ce97b80) at rtp_engine.c:569
> #7  0x00007ff69acdc4fc in ast_rtp_ice_start_media (status=<optimized out>, ice=0x7ff68801e9c8) at res_rtp_asterisk.c:2172
> #8  ast_rtp_on_ice_complete (ice=0x7ff68801e9c8, status=<optimized out>) at res_rtp_asterisk.c:2217
> #9  0x00007ff76efe9eb5 in on_timer (th=<optimized out>, te=<optimized out>) at ../src/pjnath/ice_session.c:1177
> #10 0x00007ff76f065147 in pj_timer_heap_poll (ht=0x4ba32b8, next_delay=next_delay at entry=0x0) at ../src/pj/timer.c:659
> #11 0x00007ff69acd5420 in timer_worker_thread (data=<optimized out>) at res_rtp_asterisk.c:2296
> #12 0x00007ff76f04e1a0 in thread_main (param=0x5faac00) at ../src/pj/os_core_unix.c:541
> #13 0x00007ff76d09be65 in start_thread () from /usr/lib64/libpthread.so.0
> #14 0x00007ff76c43d88d in clone () from /usr/lib64/libc.so.6
> Related code lines (res_rtp_asterisk.c:6159) is: ast_free(rtp->rtcp->local_addr_str);
> Seems like rtp->rtcp->local_addr_str memory was corrupt (released, allocated or wrote) and libc asserts it.
> We attach additional information.
> ¿Does anyone know if it’s a known issue?
> We can colaborate testing or getting additional information.



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