[ https://issues.apache.org/jira/browse/ZOOKEEPER-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962615#comment-14962615 ]
Raul Gutierrez Segales commented on ZOOKEEPER-1029: --------------------------------------------------- Actually, I can't repro this using https://gist.github.com/rgs1/998684a0e93c072cb65d Can someone provide a repro? > 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 > Assignee: Raul Gutierrez Segales > Priority: Blocker > Fix For: 3.4.7, 3.5.2 > > Attachments: ZOOKEEPER-1029.patch > > > 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)