[Home]

Summary:ASTERISK-26713: Segfault when removing object from cache
Reporter:Ross Beer (rossbeer)Labels:
Date Opened:2017-01-11 15:03:50.000-0600Date Closed:2017-01-17 10:32:52.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Core/Sorcery
Versions:13.13.1 Frequency of
Occurrence		Occasional
Related
Issues:
is related toASTERISK-26706 Segfault in dial_target_free stasis_channels.c:1349
Environment:Fedora 23Attachments:
Description:Segfault occurs when removing endpoint from the cache. The interesting thing here is that the endpoint is not in real-time but in the fixed config.

{noformat}
#0  0x00007f2c0fec8a28 in raise () at /lib64/libc.so.6
#1  0x00007f2c0feca62a in abort () at /lib64/libc.so.6
#2  0x00007f2c0ff0bdea in  () at /lib64/libc.so.6
#3  0x00007f2c0ff14936 in _int_free () at /lib64/libc.so.6
#4  0x00007f2c0ff1778c in free () at /lib64/libc.so.6
#5  0x00000000004dfd60 in ast_variable_destroy (doomed=0x7f2bc851fc50) at config.c:548
#6  0x00000000004dfec6 in ast_variables_destroy (v=0x7f2bc851fce0) at config.c:604
       vn = 0x7f2bc851fc50
#7  0x00007f2b809a18ed in sorcery_memory_cached_object_destructor (obj=0x7f2bc836b220) at res_sorcery_memory_cache.c:433
       cached = 0x7f2bc836b220
#8  0x000000000045e7c6 in internal_ao2_ref (user_data=0x7f2bc836b220, delta=-1, file=0x6b8fbb "astobj2.c", line=505, func=0x6b9248 <__FUNCTION__.8761> "__ao2_ref") at astobj2.c:438
       obj = 0x7f2bc836b208
       obj_mutex = 0x7f2bc836b220
       obj_rwlock = 0x7f2b5ed5e8a0
       current_value = 0
       ret = 1
       __PRETTY_FUNCTION__ = "internal_ao2_ref"
#9  0x000000000045ea77 in __ao2_ref (user_data=0x7f2bc836b220, delta=-1) at astobj2.c:505
       __FUNCTION__ = "__ao2_ref"
#10 0x00007f2b809a1976 in remove_from_cache (cache=0x1dd15d8, id=0x3126450 "inbound03", reschedule=1) at res_sorcery_memory_cache.c:471
       hash_object = 0x7f2bc836b220
       oldest_object = 0x7f2bd00175b0
       heap_object = 0x7f2bc836b220
#11 0x00007f2b809a2248 in sorcery_memory_cache_create (sorcery=0x1dce4d0, data=0x1dd15d8, object=0x3126668) at res_sorcery_memory_cache.c:810
       cache = 0x1dd15d8
       cached = 0x7f2bc863b720
       __PRETTY_FUNCTION__ = "sorcery_memory_cache_create"
#12 0x00000000005cb134 in sorcery_cache_create (obj=0x1dd15a0, arg=0x7f2b5ed5e9a0, flags=0) at sorcery.c:1854
       object_wizard = 0x1dd15a0
       details = 0x7f2b5ed5e9a0
#13 0x00000000005cb2ed in ast_sorcery_retrieve_by_id (sorcery=0x1dce4d0, type=0x7f2b650a81d0 "endpoint", id=0x3bfc232 "<< ENDPOINT >>") at sorcery.c:1890
       rc = 0
       idx = 1
       res = 0x0
       sdetails = {sorcery = 0x1dce4d0, obj = 0x3126668}
       object_type = 0x1dd0cf0
       object = 0x3126668
       i = 0
       cached = 0
       __PRETTY_FUNCTION__ = "ast_sorcery_retrieve_by_id"
#14 0x00007f2b650a71cf in ip_identify (rdata=<optimized out>) at res_pjsip_endpoint_identifier_ip.c:141
       addr = {ss = {ss_family = 2, __ss_padding = "\023\304%\235\066\312", '\000' <repeats 111 times>, __ss_align = 0}, len = 16}
       candidates = 0x7f2bc80754f8
       match = 0x3d32468
       endpoint = <optimized out>
       __PRETTY_FUNCTION__ = "ip_identify"
#15 0x00007f2b813f7322 in ast_sip_identify_endpoint (rdata=rdata@entry=0x7f2bc81f3da8) at res_pjsip.c:2527
       iter = 0x21d7dc0
{noformat}
Comments:By: Asterisk Team (asteriskteam) 2017-01-11 15:03:51.633-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Richard Mudgett (rmudgett) 2017-01-11 16:41:45.026-0600

These segfaults you are seeing in malloc() or free() are almost certainly the result of memory corruption.  A bug causing memory corruption issues can cause a crash anywhere.