[Home]

Summary:ASTERISK-26667: sorcery: Segfault in res_sorcery_memory_cache, in ast_sorcery_object_get_id at sorcery.c
Reporter:Jesse Ross (jmross)Labels:
Date Opened:2016-12-20 12:24:40.000-0600Date Closed:
Priority:CriticalRegression?
Status:Open/NewComponents:Resources/res_sorcery_memory_cache
Versions:13.12.2 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:Ubuntu 16.04.1 Kernel 4.4.0-53Attachments:( 0) backtrace.txt
( 1) debug.txt
( 2) gdb.txt
( 3) sorcery.conf
Description:Asterisk crashes 2-3 times a day with this outputted to /var/log/syslog:
{noformat}
Dec 20 12:45:00 voip kernel: [618425.917499] asterisk[14173]: segfault at 0 ip 00000000005e0755 sp 00007fc6aafb6cc0 error 4 in asterisk[400000+2ca000]
{noformat}
No calls were happening. 4 devices were registered to Asterisk.


This is the last output to the Asterisk debug log:
{noformat}
[2016-12-20 12:45:00] DEBUG[14541] res_sorcery_memory_cache.c: Cached sorcery object type 'endpoint' ID '1234' is stale. Refreshing
[2016-12-20 12:45:00] DEBUG[14173] res_config_odbc.c: Skip: 0; SQL: SELECT * FROM ps_endpoints WHERE id = ?
[2016-12-20 12:45:00] DEBUG[14173] res_config_odbc.c: Parameter 1 ('id') = '1234'
[2016-12-20 12:45:00] DEBUG[14173] res_sorcery_realtime.c: Filtering out realtime field 'disallow' from retrieval
[2016-12-20 12:45:00] DEBUG[14173] res_sorcery_memory_cache.c: Refreshing stale cache object type 'endpoint' ID '1234'
{noformat}
I changed the ID of the endpoint above for security.
Comments:By: Asterisk Team (asteriskteam) 2016-12-20 12:24:41.056-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: Rusty Newton (rnewton) 2016-12-22 09:03:33.929-0600

It may be a lot to sanitize, but if you can provide us a longer debug log (warning,error,notice,debug,verbose) with both debug and verbose turned up to 5. It would be nice to have a few thousand lines before the crash. Often we need to trace back a bit further to see what sort of state things are in.
By: Jesse Ross (jmross) 2016-12-22 09:43:23.654-0600

I uploaded a longer debug file. Unfortunately, that's all I have at the moment. I will have to get back to you with a better log with verbose and debugging on 5.

I have disabled adding anything to the sorcery cache in sorcery.conf and I have not had the issue since.

We are using an external administration site that stales objects in the cache through AMI when the database is updated.