Summary: | ASTERISK-25058: res_pjsip_pubsub: Crash in ast_sorcery_hash called from subscription_persistence_update | ||||
Reporter: | Matt Jordan (mjordan) | Labels: | |||
Date Opened: | 2015-05-04 21:39:58 | Date Closed: | 2015-05-06 10:49:08 | ||
Priority: | Major | Regression? | |||
Status: | Closed/Complete | Components: | Core/Sorcery Resources/res_pjsip_pubsub | ||
Versions: | 13.3.2 | Frequency of Occurrence | |||
Related Issues: |
| ||||
Environment: | Attachments: | ||||
Description: | A crash was detected during normal operation of Asterisk. While we're missing some of the backtrace, the {{core}} file still provided a good bit of information.
{code} Program terminated with signal 11, Segmentation fault. #0 0x081d773c in sorcery_type_hash () (gdb) bt full #0 0x081d773c in sorcery_type_hash () No symbol table info available. #1 0x0809ae18 in hash_ao2_find_first () No symbol table info available. #2 0x08099590 in internal_ao2_traverse () No symbol table info available. #3 0x080998fc in __ao2_callback () No symbol table info available. #4 0x08099a3e in __ao2_find () No symbol table info available. #5 0x081daf97 in ast_sorcery_update () No symbol table info available. #6 0x04526b61 in subscription_persistence_update (sub_tree=0x894c3ac, rdata=0x0) at res_pjsip_pubsub.c:573 dlg = 0x911b05c #7 0x04529a08 in sip_subscription_send_request (sub_tree=0x894c3ac, tdata=0xb227dfc4) at res_pjsip_pubsub.c:1639 res = 0 __PRETTY_FUNCTION__ = "sip_subscription_send_request" #8 0x0452a6f7 in send_notify (sub_tree=0x894c3ac, force_full_state=0) at res_pjsip_pubsub.c:2078 evsub = 0x911c634 tdata = 0xb227dfc4 #9 0x0452a911 in ast_sip_subscription_notify (sub=0x893932c, notify_data=0xb1fa70f4, terminate=0) at res_pjsip_pubsub.c:2154 res = 134840417 #10 0x03d44524 in notify_task (obj=0xb75a2274) at res_pjsip_exten_state.c:240 task_data = 0xb75a2274 data = {body_type = 0x3d44eee "ast_sip_exten_state_data", body_data = 0xb75a2274} #11 0x081f50bc in ast_taskprocessor_execute () No symbol table info available. #12 0x081fd13d in execute_tasks () No symbol table info available. #13 0x081f50bc in ast_taskprocessor_execute () No symbol table info available. #14 0x081fba29 in threadpool_execute () No symbol table info available. #15 0x081fce60 in worker_active () No symbol table info available. #16 0x081fcc20 in worker_start () ---Type <return> to continue, or q <return> to quit--- No symbol table info available. #17 0x0820725c in dummy_start () No symbol table info available. #18 0x009f8b39 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #19 0x00908c2e in clone () from /lib/libc.so.6 No symbol table info available. {code} Since we don't have the core backtraces (and most of this is iterating over an ao2 container, in which either it or an object is invalid withint it), starting at {{subscription_persistence_update}} is reasonable. {code} 573: ast_sorcery_update(ast_sip_get_sorcery(), sub_tree->persistence); {code} Looking at {{sub_tree}} and {{sub_tree->persistence}}: {code} (gdb) print *sub_tree $1 = {endpoint = 0x91199bc, serializer = 0x895cbc4, role = AST_SIP_NOTIFIER, persistence = 0x911d874, evsub = 0x911c634, dlg = 0x911b05c, notification_batch_interval = 0, notify_sched_id = -1, send_scheduled_notify = 0, root = 0x893932c, is_list = 0, next = {next = 0x68}} (gdb) print *sub_tree->persistence $2 = {{details = {object = 0x6d736e61}}, endpoint = 0x69747469 <Address 0x69747469 out of bounds>, packet = "ng SIP response (649 bytes) to UDP:XXX.XXX.XXX.XXX:XXXX --->\n\377SIP/2.0 200 OK\r\n\377Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:XXXX;rport=XXXX;received=XXX.XXX.XXX.XXX;branch=z9hG4bKPjlCtq7iOtRrwZdR3VVRL0t2alxoa6FyXw\r\n\377Call-"..., src_name = "XXX.XXX.XXX.XXX", '\000' <repeats 32 times>, src_port = XXXX, transport_key = "UDP", '\000' <repeats 17 times>"\241, \000\000\000\320є\bP\222\003\t", local_name = "XXX.XXX.XXX.XXX", '\000' <repeats 36 times>, local_port = 5060, cseq = 26080, tag = 0x910a038 "\340\260\034\t\270\271\377\b\b_$\t", expires = {tv_sec = 1430486138, tv_usec = 532172}} (gdb) {code} That {{persistence}} object looks a little funny. Some of it looks reasonable... other parts, not so much. In particular, the {{endpoint}} object being out of bounds seems a bit wrong. Note that the parts that are reasonable are set in the code just prior to the call to {{ast_sorcery_update}}, so some of that struct looking okay is to be expected. Looking at {{ast_sorcery_update}}, we can see that the call to {{ao2_find}} happens here: {code} RAII_VAR(struct ast_sorcery_object_type *, object_type, ao2_find(sorcery->types, details->object->type, OBJ_KEY), ao2_cleanup); {code} Since the type is {{OBJ_KEY}}, we are likely to be crashing when calling {{ast_str_hash}} on an invalid pointer: {code} /*! \brief Hashing function for sorcery types */ static int sorcery_type_hash(const void *obj, const int flags) { const struct ast_sorcery_object_type *object; const char *key; switch (flags & OBJ_SEARCH_MASK) { case OBJ_SEARCH_KEY: key = obj; break; case OBJ_SEARCH_OBJECT: object = obj; key = object->name; break; default: ast_assert(0); return 0; } return ast_str_hash(key); } {code} However, it is not clear why the sorcery object is messed up. | ||||
Comments: |