You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Steven Schlansker (JIRA)" <ji...@apache.org> on 2015/04/24 22:16:40 UTC
[jira] [Commented] (ZOOKEEPER-1029) C client bug in zookeeper_init
(if bad hostname is given)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14511654#comment-14511654 ]
Steven Schlansker commented on ZOOKEEPER-1029:
----------------------------------------------
This causes serious issues with clustering software e.g. Mesos has a critical bug open over this:
https://issues.apache.org/jira/browse/MESOS-2186
> C client bug in zookeeper_init (if bad hostname is given)
> ---------------------------------------------------------
>
> Key: ZOOKEEPER-1029
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1029
> Project: ZooKeeper
> Issue Type: Bug
> Components: c client
> Affects Versions: 3.3.2
> Reporter: Dheeraj Agrawal
>
> If you give invalid hostname to zookeeper_init method, it's not able to resolve it, and it tries to do the cleanup (free buffer/completion lists/etc) . The adaptor_init() is not called for this code path, so the lock,cond variables (for adaptor, completion lists) are not initialized.
> As part of the cleanup it's trying to clean up some buffers and acquires locks and unlocks (where the locks have not yet been initialized, so unlocking fails)
> lock_completion_list(&zh->sent_requests); - pthread_mutex/cond not initialized
> tmp_list = zh->sent_requests;
> zh->sent_requests.head = 0;
> zh->sent_requests.last = 0;
> unlock_completion_list(&zh->sent_requests); trying to broadcast here on uninitialized cond
> It should do error checking to see if locking succeeds before unlocking it. If Locking fails, then appropriate error handling has to be done.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)