[asterisk-bugs] [JIRA] (ASTERISK-25323) Asterisk: ongoing segfaults uncovered by CHAOS_DEBUG

Scott Griepentrog (JIRA) noreply at issues.asterisk.org
Mon Aug 17 10:21:33 CDT 2015


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

Scott Griepentrog commented on ASTERISK-25323:
----------------------------------------------

Instance #1: crash in ast_str_hash due to null str

{{noformat}}
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `asterisk -fvvvvvdddddgn'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007fe9dc111f4a in ast_str_hash (str=0x0) at /root/13-c57b78d4c94e592d069521123a24fcb80524a893/include/asterisk/strings.h:1180
1180		while (*str)
#0  0x00007fe9dc111f4a in ast_str_hash (str=0x0) at /root/13-c57b78d4c94e592d069521123a24fcb80524a893/include/asterisk/strings.h:1180
        hash = 5381
#1  0x00007fe9dc111f99 in sorcery_memory_hash (obj=0x0, flags=64) at res_sorcery_memory.c:88
        id = 0x0
#2  0x000000000045ffb6 in hash_ao2_find_first (self=0x1ed5568, flags=65, arg=0x0, state=0x7fe9d270f5e0) at astobj2_hash.c:388
        node = 0x1ed5510
        bucket_cur = 0
        cmp = 7185311
#3  0x000000000045e34f in internal_ao2_traverse (self=0x1ed5568, flags=65, cb_fn=0x7fe9dc111f9b <sorcery_memory_cmp>, arg=0x0, data=0x0, type=AO2_CALLBACK_DEFAULT, tag=0x0, file=0x0, line=0, func=0x0) at astobj2_container.c:341
        ret = 0x0
        cb_default = 0x7fe9dc111f9b <sorcery_memory_cmp>
        cb_withdata = 0x0
        node = 0x7fe9d270f7b0
        traversal_state = 0x7fe9d270f5e0
        orig_lock = AO2_LOCK_REQ_MUTEX
        multi_container = 0x0
        multi_iterator = 0x0
        __PRETTY_FUNCTION__ = "internal_ao2_traverse"
#4  0x000000000045e6bb in __ao2_callback (c=0x1ed5568, flags=65, cb_fn=0x7fe9dc111f9b <sorcery_memory_cmp>, arg=0x0) at astobj2_container.c:452
No locals.
#5  0x000000000045e86e in __ao2_find (c=0x1ed5568, arg=0x0, flags=65) at astobj2_container.c:493
        arged = 0x0
        __PRETTY_FUNCTION__ = "__ao2_find"
#6  0x00007fe9dc11240a in sorcery_memory_update (sorcery=0x1e77d28, data=0x1ed5568, object=0x7fe9f4003ca0) at res_sorcery_memory.c:193
        existing = 0x0
        __PRETTY_FUNCTION__ = "sorcery_memory_update"
#7  0x00000000005c16e7 in sorcery_wizard_update (obj=0x1ed4ae8, arg=0x7fe9d270f880, flags=0) at sorcery.c:2045
        object_wizard = 0x1ed4ae8
        details = 0x7fe9d270f880
        __PRETTY_FUNCTION__ = "sorcery_wizard_update"
#8  0x00000000005c1829 in ast_sorcery_update (sorcery=0x1e77d28, object=0x7fe9f4003ca0) at sorcery.c:2068
        details = 0x7fe9f4003ca0
        object_type = 0x1ed4b68
        object_wizard = 0x0
        found_wizard = 0x1ed4ae8
        i = 0
        sdetails = {sorcery = 0x1e77d28, obj = 0x7fe9f4003ca0}
        __PRETTY_FUNCTION__ = "ast_sorcery_update"
#9  0x00007fe9d32cd802 in update_contact_status (contact=0x1fae9b0, value=value at entry=AVAILABLE) at res_pjsip/pjsip_options.c:162
        status = 0x7fe9f4001dd0
        update = 0x7fe9f4003ca0
        __PRETTY_FUNCTION__ = "update_contact_status"
#10 0x00007fe9d32cdd62 in qualify_contact_cb (token=0x1fae9b0, e=<optimized out>) at res_pjsip/pjsip_options.c:303
        contact = 0x1fae9b0
        __PRETTY_FUNCTION__ = "qualify_contact_cb"
#11 0x00007fe9d32c8e00 in send_request_cb (token=0x7fe9f4000c90, e=0x7fe9d270f9c0) at res_pjsip.c:3224
        req_data = 0x7fe9f4000c90
        tsx = 0x1c24e78
        challenge = 0x7fe9e0051828
        tdata = 0x7fe9f4000cc0
        supplement = <optimized out>
        endpoint = <optimized out>
        res = <optimized out>
        __PRETTY_FUNCTION__ = "send_request_cb"
#12 0x00007fe9d32c8657 in endpt_send_request_cb (token=0x7fe9f4000ce0, e=0x7fe9d270f9c0) at res_pjsip.c:3005
        req_wrapper = 0x7fe9f4000ce0
        __PRETTY_FUNCTION__ = "endpt_send_request_cb"
#13 0x00007fe9df28697a in tsx_set_state () from /lib64/libpjsip.so.2
No symbol table info available.
#14 0x00007fe9df2885f6 in tsx_on_state_proceeding_uac () from /lib64/libpjsip.so.2
No symbol table info available.
#15 0x00007fe9df28883d in tsx_on_state_calling () from /lib64/libpjsip.so.2
No symbol table info available.
#16 0x00007fe9df289d0f in pjsip_tsx_recv_msg () from /lib64/libpjsip.so.2
No symbol table info available.
#17 0x00007fe9df289db5 in mod_tsx_layer_on_rx_response () from /lib64/libpjsip.so.2
No symbol table info available.
#18 0x00007fe9df27445f in pjsip_endpt_process_rx_data () from /lib64/libpjsip.so.2
No symbol table info available.
#19 0x00007fe9d32d27b9 in distribute (data=0x7fe9e0051828) at res_pjsip/pjsip_distributor.c:439
        param = {start_prio = 0, start_mod = 0x7fe9d34f0760 <distributor_mod>, idx_after_start = 1, silent = 0}
        handled = 0
        rdata = 0x7fe9e0051828
        is_request = 0
        is_ack = 0
        endpoint = <optimized out>
#20 0x00000000005e0e92 in ast_taskprocessor_execute (tps=0x1e762b8) at taskprocessor.c:768
        local = {local_data = 0x7fe9d27109c0, data = 0x5f6c79 <ast_threadstorage_set_ptr+60>}
        t = 0x7fe9e04f25d0
        size = 0
        __PRETTY_FUNCTION__ = "ast_taskprocessor_execute"
#21 0x00000000005ecccd in execute_tasks (data=0x1e762b8) at threadpool.c:1269
        tps = 0x1e762b8
#22 0x00000000005e0e92 in ast_taskprocessor_execute (tps=0x1e765b8) at taskprocessor.c:768
        local = {local_data = 0x55cc0c76, data = 0x1e60a80}
        t = 0x7fe9e04b7e20
        size = 0
        __PRETTY_FUNCTION__ = "ast_taskprocessor_execute"
#23 0x00000000005eb144 in threadpool_execute (pool=0x1e60ad8) at threadpool.c:351
        __PRETTY_FUNCTION__ = "threadpool_execute"
#24 0x00000000005ec662 in worker_active (worker=0x7fe9e8006bc8) at threadpool.c:1075
        alive = 0
#25 0x00000000005ec41f in worker_start (arg=0x7fe9e8006bc8) at threadpool.c:995
        worker = 0x7fe9e8006bc8
        __PRETTY_FUNCTION__ = "worker_start"
#26 0x00000000005f855b in dummy_start (data=0x7fe9e801c030) at utils.c:1237
        __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, 7449420058881167766, 0, 140642234730944, 140642234730240, 20, 7449420058906333590, -7443873705584488042}, __mask_was_saved = 0}}, __pad = {0x7fe9d270fdf0, 0x0, 0x0, 0x7fe9ff6162e8 <__pthread_keys+8>}}
        __cancel_routine = 0x4510a7 <ast_unregister_thread>
        __cancel_arg = 0x7fe9d2710700
        __not_first_call = 0
        ret = 0x7fe9fe9a7860 <internal_trans_names.8316>
        a = {start_routine = 0x5ec398 <worker_start>, data = 0x7fe9e8006bc8, name = 0x7fe9e8002fc0 "worker_start         started at [ 1049] threadpool.c worker_thread_start()"}
#27 0x00007fe9ff406df5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#28 0x00007fe9fe6e71ad in clone () from /lib64/libc.so.6
{{noformat}}


> Asterisk: ongoing segfaults uncovered by CHAOS_DEBUG
> ----------------------------------------------------
>
>                 Key: ASTERISK-25323
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25323
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 13.0.0
>            Reporter: Scott Griepentrog
>            Severity: Minor
>
> Ongoing use of CHAOS_DEBUG on a test server is uncovering extremely unlikely scenarios that can result in a segfault, by use of randomly simulating a failed allocation.
> Rather than create a new issue for each case, I'm grouping them under this single issue as they are found.



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



More information about the asterisk-bugs mailing list