[asterisk-bugs] [JIRA] (ASTERISK-26199) PJSIP: tx_data_destroy called twice

[Malcolm Davenport (JIRA)]

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

Malcolm Davenport closed ASTERISK-26199.
----------------------------------------

    Resolution: Fixed

https://gerrit.asterisk.org/#/c/3254/

> PJSIP: tx_data_destroy called twice
> -----------------------------------
>
>                 Key: ASTERISK-26199
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26199
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: pjproject/pjsip
>         Environment: Asterisk 13 from GIT HEAD, pjproject 2.4.5, running on a VM with 4 cores
>            Reporter: Scott Griepentrog
>
> During testing under valgrind, it was disovered that tx_data_destroy() can be called on a structure that has already been free'd by a previous call to tx_data_destroy() from pubsub's send_notify failing on a sip_subscription_send_request().  While not easily reproducible, I have observed this happening several times.
> {noformat}
> ==44484== Invalid read of size 1
> ==44484==    at 0x73C0AB4: vfprintf (vfprintf.c:1635)
> ==44484==    by 0x73EC598: vsnprintf (vsnprintf.c:119)
> ==44484==    by 0x109F1542: pj_log (log.c:442)
> ==44484==    by 0x109F19D3: pj_log_5 (log.c:535)
> ==44484==    by 0xEE1975D: tx_data_destroy (sip_transport.c:469)
> ==44484==    by 0xEE197E6: pjsip_tx_data_dec_ref (sip_transport.c:496)
> ==44484==    by 0xEE2B7D5: tsx_shutdown (sip_transaction.c:1059)
> ==44484==    by 0xEE2BD50: tsx_set_state (sip_transaction.c:1248)
> ==44484==    by 0xEE2EF7C: tsx_on_state_terminated (sip_transaction.c:3323)
> ==44484==    by 0xEE2BAA2: tsx_timer_callback (sip_transaction.c:1156)
> ==44484==    by 0x109FE371: pj_timer_heap_poll (timer.c:643)
> ==44484==    by 0xEE13231: pjsip_endpt_handle_events2 (sip_endpoint.c:712)
> ==44484==    by 0xEE13362: pjsip_endpt_handle_events (sip_endpoint.c:769)
> ==44484==    by 0x1767A40B: monitor_thread_exec (res_pjsip.c:3870)
> ==44484==    by 0x109E89FE: thread_main (os_core_unix.c:541)
> ==44484==    by 0x6715DC4: start_thread (pthread_create.c:308)
> ==44484==    by 0x746ECEC: clone (clone.S:113)
> ==44484==  Address 0x410ebc78 is 4,520 bytes inside a block of size 8,000 free'd
> ==44484==    at 0x4C2AD17: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==44484==    by 0x109EAF47: default_block_free (pool_policy_malloc.c:78)
> ==44484==    by 0x109F276A: reset_pool (pool.c:254)
> ==44484==    by 0x109F27EC: pj_pool_reset (pool.c:276)
> ==44484==    by 0x109F3024: cpool_release_pool (pool_caching.c:247)
> ==44484==    by 0x109F22E1: pj_pool_release (pool_i.h:92)
> ==44484==    by 0xEE131D1: pjsip_endpt_release_pool (sip_endpoint.c:688)
> ==44484==    by 0xEE197B4: tx_data_destroy (sip_transport.c:485)
> ==44484==    by 0xEE197E6: pjsip_tx_data_dec_ref (sip_transport.c:496)
> ==44484==    by 0x133D6923: send_notify (res_pjsip_pubsub.c:2274)
> ==44484==    by 0x133DA44C: serialized_pubsub_on_refresh_timeout (res_pjsip_pubsub.c:3488)
> ==44484==    by 0x5DBD13: ast_taskprocessor_execute (taskprocessor.c:938)
> ==44484==    by 0x5E4796: execute_tasks (threadpool.c:1322)
> ==44484==    by 0x5DBD13: ast_taskprocessor_execute (taskprocessor.c:938)
> ==44484==    by 0x5E2AD8: threadpool_execute (threadpool.c:351)
> ==44484==    by 0x5E411A: worker_active (threadpool.c:1105)
> ==44484==    by 0x5E3ED3: worker_start (threadpool.c:1024)
> ==44484==    by 0x5EFBE3: dummy_start (utils.c:1235)
> ==44484==    by 0x6715DC4: start_thread (pthread_create.c:308)
> ==44484==    by 0x746ECEC: clone (clone.S:113)
> {noformat}



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