[ https://issues.apache.org/jira/browse/ZOOKEEPER-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14586493#comment-14586493 ]
Raul Gutierrez Segales commented on ZOOKEEPER-1029: --------------------------------------------------- The ZooKeeper client should probably just keep retrying the lookups from the IO thread (i.e.: it could very well be transient). I don't think a failed DNS lookup should be coupled with failing the ZK handler (at all). > 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, 3.4.6, 3.5.0 > Reporter: Dheeraj Agrawal > Fix For: 3.4.7, 3.5.1 > > > 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)