[jira] [Commented] (ZOOKEEPER-1029) C client bug in zookeeper_init (if bad hostname is given)

["Stefan Boberg (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585202#comment-13585202 ] 

Stefan Boberg commented on ZOOKEEPER-1029:
------------------------------------------

This still happens with latest (3.4.x). On Windows it actually crashes even earlier actually, at the inital lock. 

The cleanup code should ideally detect that the lists haven't been initialized and skip the teardown logic. From a cursory look it looks like this might require some explicit flags to indicate the current state to the cleanup code.

I'd have a go myself but I am unfortunately very new to the codebase, and it seems like there's not a whole lot of interest in fixing this fairly serious issue... which in turn makes me wonder if I should use Zookeeper from C/C++! Because if this doesn't get fixed, who knows what other issues exist?

                
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira