Summary: | ASTERISK-26199: PJSIP: tx_data_destroy called twice | ||||||
Reporter: | Scott Griepentrog (sgriepentrog) | Labels: | |||||
Date Opened: | 2016-07-14 15:25:25 | Date Closed: | 2016-09-01 09:41:16 | ||||
Priority: | Major | Regression? | |||||
Status: | Closed/Complete | Components: | pjproject/pjsip | ||||
Versions: | Frequency of Occurrence | Occasional | |||||
Related Issues: |
| ||||||
Environment: | Asterisk 13 from GIT HEAD, pjproject 2.4.5, running on a VM with 4 cores | Attachments: | |||||
Description: | 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} | ||||||
Comments: | By: Malcolm Davenport (mdavenport) 2016-09-01 09:41:16.811-0500 https://gerrit.asterisk.org/#/c/3254/ |