reentrant_mutex_fix.diff
|
Duplicate |
|||
| is duplicated by |
|
vmware collector remains after zabbix... | Closed |
[ZBX-11635] Deadlock on zbx_mutex_lock(&log_access) when vmware_service_remove is called Created: 2016 Dec 22 Updated: 2018 Jul 19 Resolved: 2017 Jan 09 |
|
| Status: | Closed |
| Project: | ZABBIX BUGS AND ISSUES |
| Component/s: | Server (S) |
| Affects Version/s: | 2.2.17rc1, 3.0.7, 3.2.4rc1, 3.4.0alpha1 |
| Fix Version/s: | 2.2.17rc1, 3.0.8rc1, 3.2.4rc1, 3.4.0alpha1 |
| Type: | Incident report | Priority: | Blocker |
| Reporter: | Jasper Molenmaker | Assignee: | Unassigned |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | crash | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
reentrant_mutex_fix.diff
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
Occurs when log level is set to debug. In vmware.c module on line 3827 a string parameter is missing in the call to "zabbix_log" . This will case the "fatal_signal_handler" to be called. "zabbix_log" has a lock on the log_access mutex. The fatal_signal_handler also wants to log and is requesting the same mutex. Hence a deadlock occurs. To make things worse all other threads that want to log will end up in the same deadlock causing whole Zabbix server to hang. Advice is (besides fixing the bug) to rewrite the fatal signal handler so it does not depend on the log mutex to do its work. |
| Comments |
| Comment by Glebs Ivanovskis (Inactive) [ 2016 Dec 22 ] |
|
The line in question:
zabbix_log(LOG_LEVEL_DEBUG, "End of %s()");
Seems that it was introduced in Moved to ZBX project. |
| Comment by Sergejs Paskevics [ 2016 Dec 30 ] |
|
Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-11635 |
| Comment by Vladislavs Sokurenko [ 2017 Jan 05 ] |
|
successfully tested, also attached patch for 3.2 with idea that can be used to fix similar issues in the future if needed. |
| Comment by Sergejs Paskevics [ 2017 Jan 09 ] |
|
Fixed in:
|