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

[Raul Gutierrez Segales (JIRA)]

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

Raul Gutierrez Segales commented on ZOOKEEPER-1029:
---------------------------------------------------

I think it's a good start, though we might want to check return codes for these 
ones too:

{code}
void enter_critical(zhandle_t* zh)
{
    struct adaptor_threads *adaptor = zh->adaptor_priv;
    if(adaptor)
        pthread_mutex_lock(&adaptor->zh_lock);
}

void leave_critical(zhandle_t* zh)
{
    struct adaptor_threads *adaptor = zh->adaptor_priv;
    if(adaptor)
        pthread_mutex_unlock(&adaptor->zh_lock);
}
{code}

We can probably leave that for another round. Unless there's anything else 
you'd like to add, I'll go ahead and merge this. 

> 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: Flavio Junqueira
>            Priority: Blocker
>             Fix For: 3.4.7, 3.5.2
>
>         Attachments: ZOOKEEPER-1029-3.4.patch, ZOOKEEPER-1029-3.4.patch, 
> ZOOKEEPER-1029-3.4.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)