[asterisk-bugs] [JIRA] (ASTERISK-24556) Asterisk 13 core dumps when calling from pjsip extension to another pjsip extension

Abhay Gupta (JIRA) noreply at issues.asterisk.org
Tue Nov 25 07:05:28 CST 2014


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

Abhay Gupta commented on ASTERISK-24556:
----------------------------------------

Invalid read of size 4
==28948==    at 0xBCF0E38: pjsip_msg_find_hdr (sip_msg.c:347)
==28948==    by 0xBCFFC54: pjsip_get_request_dest (sip_util.c:902)
==28948==    by 0xBD16F27: pjsip_tsx_create_uac2 (sip_transaction.c:1376)
==28948==    by 0xBD16C03: pjsip_tsx_create_uac (sip_transaction.c:1270)
==28948==    by 0xBD1C7D3: pjsip_dlg_send_request (sip_dialog.c:1214)
==28948==    by 0xBACF7F9: pjsip_inv_send_msg (sip_inv.c:3102)
==28948==    by 0xB8BEA50: send_delayed_request (res_pjsip_session.c:530)
==28948==    by 0xB8BEB8C: really_resend_reinvite (res_pjsip_session.c:1716)
==28948==    by 0x5E587E: ast_taskprocessor_execute (taskprocessor.c:769)
==28948==    by 0x5EDE64: execute_tasks (threadpool.c:1157)
==28948==    by 0x5E587E: ast_taskprocessor_execute (taskprocessor.c:769)
==28948==    by 0x5EC66F: threadpool_execute (threadpool.c:351)
==28948==  Address 0x74468a8 is 2,712 bytes inside a block of size 4,000 free'd
==28948==    at 0x4C2A82E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28948==    by 0xC3DEEEB: default_block_free (pool_policy_malloc.c:78)
==28948==    by 0xC3E6B4A: reset_pool (pool.c:254)
==28948==    by 0xC3E6BD2: pj_pool_reset (pool.c:276)
==28948==    by 0xC3E740C: cpool_release_pool (pool_caching.c:247)
==28948==    by 0xC3E66BC: pj_pool_release (pool_i.h:92)
==28948==    by 0xBCFD184: pjsip_endpt_release_pool (sip_endpoint.c:688)
==28948==    by 0xBD03A85: tx_data_destroy (sip_transport.c:484)
==28948==    by 0xBD03AB7: pjsip_tx_data_dec_ref (sip_transport.c:495)
==28948==    by 0xBD19A2B: tsx_on_state_proceeding_uac (sip_transaction.c:3015)
==28948==    by 0xBD18F1A: tsx_on_state_calling (sip_transaction.c:2493)
==28948==    by 0xBD17961: pjsip_tsx_recv_msg (sip_transaction.c:1765)
==28948== 
==28948== Invalid read of size 8
==28948==    at 0xBCF0E4A: pjsip_msg_find_hdr (sip_msg.c:346)
==28948==    by 0xBCFFC54: pjsip_get_request_dest (sip_util.c:902)
==28948==    by 0xBD16F27: pjsip_tsx_create_uac2 (sip_transaction.c:1376)
==28948==    by 0xBD16C03: pjsip_tsx_create_uac (sip_transaction.c:1270)
==28948==    by 0xBD1C7D3: pjsip_dlg_send_request (sip_dialog.c:1214)
==28948==    by 0xBACF7F9: pjsip_inv_send_msg (sip_inv.c:3102)
==28948==    by 0xB8BEA50: send_delayed_request (res_pjsip_session.c:530)
==28948==    by 0xB8BEB8C: really_resend_reinvite (res_pjsip_session.c:1716)
==28948==    by 0x5E587E: ast_taskprocessor_execute (taskprocessor.c:769)
==28948==    by 0x5EDE64: execute_tasks (threadpool.c:1157)
==28948==    by 0x5E587E: ast_taskprocessor_execute (taskprocessor.c:769)
==28948==    by 0x5EC66F: threadpool_execute (threadpool.c:351)
==28948==  Address 0x74468a0 is 2,704 bytes inside a block of size 4,000 free'd
==28948==    at 0x4C2A82E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28948==    by 0xC3DEEEB: default_block_free (pool_policy_malloc.c:78)
==28948==    by 0xC3E6B4A: reset_pool (pool.c:254)
==28948==    by 0xC3E6BD2: pj_pool_reset (pool.c:276)
==28948==    by 0xC3E740C: cpool_release_pool (pool_caching.c:247)
==28948==    by 0xC3E66BC: pj_pool_release (pool_i.h:92)
==28948==    by 0xBCFD184: pjsip_endpt_release_pool (sip_endpoint.c:688)
==28948==    by 0xBD03A85: tx_data_destroy (sip_transport.c:484)
==28948==    by 0xBD03AB7: pjsip_tx_data_dec_ref (sip_transport.c:495)
==28948==    by 0xBD19A2B: tsx_on_state_proceeding_uac (sip_transaction.c:3015)
==28948==    by 0xBD18F1A: tsx_on_state_calling (sip_transaction.c:2493)
==28948==    by 0xBD17961: pjsip_tsx_recv_msg (sip_transaction.c:1765)
==28948== 
==28948== Invalid read of size 8
==28948==    at 0xC3E6595: pj_pool_alloc (pool_i.h:60)
==28948==    by 0xC3F052F: pj_strdup (string_i.h:40)
==28948==    by 0xBCFFB80: pjsip_get_dest_info (sip_util.c:857)
==28948==    by 0xBCFFCA7: pjsip_get_request_dest (sip_util.c:910)
==28948==    by 0xBD16F27: pjsip_tsx_create_uac2 (sip_transaction.c:1376)
==28948==    by 0xBD16C03: pjsip_tsx_create_uac (sip_transaction.c:1270)
==28948==    by 0xBD1C7D3: pjsip_dlg_send_request (sip_dialog.c:1214)
==28948==    by 0xBACF7F9: pjsip_inv_send_msg (sip_inv.c:3102)
==28948==    by 0xB8BEA50: send_delayed_request (res_pjsip_session.c:530)
==28948==    by 0xB8BEB8C: really_resend_reinvite (res_pjsip_session.c:1716)
==28948==    by 0x5E587E: ast_taskprocessor_execute (taskprocessor.c:769)
==28948==    by 0x5EDE64: execute_tasks (threadpool.c:1157)
==28948==  Address 0xb72606163 is not stack'd, malloc'd or (recently) free'd
==28948== 
==28948== 
==28948== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==28948==  Access not within mapped region at address 0xB72606163
==28948==    at 0xC3E6595: pj_pool_alloc (pool_i.h:60)
==28948==    by 0xC3F052F: pj_strdup (string_i.h:40)
==28948==    by 0xBCFFB80: pjsip_get_dest_info (sip_util.c:857)
==28948==    by 0xBCFFCA7: pjsip_get_request_dest (sip_util.c:910)
==28948==    by 0xBD16F27: pjsip_tsx_create_uac2 (sip_transaction.c:1376)
==28948==    by 0xBD16C03: pjsip_tsx_create_uac (sip_transaction.c:1270)
==28948==    by 0xBD1C7D3: pjsip_dlg_send_request (sip_dialog.c:1214)
==28948==    by 0xBACF7F9: pjsip_inv_send_msg (sip_inv.c:3102)
==28948==    by 0xB8BEA50: send_delayed_request (res_pjsip_session.c:530)
==28948==    by 0xB8BEB8C: really_resend_reinvite (res_pjsip_session.c:1716)
==28948==    by 0x5E587E: ast_taskprocessor_execute (taskprocessor.c:769)
==28948==    by 0x5EDE64: execute_tasks (threadpool.c:1157)
==28948==  If you believe this happened as a result of a stack
==28948==  overflow in your program's main thread (unlikely but
==28948==  possible), you can try to increase the size of the
==28948==  main thread stack using the --main-stacksize= flag.
==28948==  The main thread stack size used in this run was 8388608.
==28948== 
==28948== HEAP SUMMARY:
==28948==     in use at exit: 16,405,451 bytes in 121,390 blocks
==28948==   total heap usage: 1,774,100 allocs, 1,652,710 frees, 140,712,292 bytes allocated
==28948== 
==28948== LEAK SUMMARY:
==28948==    definitely lost: 638 bytes in 30 blocks
==28948==    indirectly lost: 65 bytes in 2 blocks
==28948==      possibly lost: 4,658,204 bytes in 18,279 blocks
==28948==    still reachable: 11,746,544 bytes in 103,079 blocks
==28948==         suppressed: 0 bytes in 0 blocks
==28948== Rerun with --leak-check=full to see details of leaked memory
==28948== 
==28948== For counts of detected and suppressed errors, rerun with: -v
==28948== Use --track-origins=yes to see where uninitialised values come from
==28948== ERROR SUMMARY: 136579 errors from 39 contexts (suppressed: 2 from 2)

> Asterisk 13 core dumps when calling from pjsip extension to another pjsip extension 
> ------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-24556
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24556
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 13.0.1
>         Environment: ubuntu 12.04 , pjproject 2.3 and asterisk 13.0.1 
>            Reporter: Abhay Gupta
>         Attachments: abhay.txt, valgrind.txt
>
>
> When i make a call from pjsip extension 6002 to 6001 it always crashes with the same core dump .
> #0  0x00007ffff4228595 in pj_pool_alloc (pool=0xb7260610b, size=13) at ../include/pj/pool_i.h:60



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



More information about the asterisk-bugs mailing list