[
https://issues.apache.org/jira/browse/ZOOKEEPER-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15347122#comment-15347122
]
Michael Han commented on ZOOKEEPER-2320:
----------------------------------------
Take a step back I am curious to know why pathHasWatcher is added into this
patch as part of the test. My guess is the return code of zoo_remove_watchers
is not enough to decide if a watch is removed or not? If we can solely rely on
the return code in the tests to decide watch remove success/fail, then we would
not need make pathHasWatcher visible outside; if we can't rely on return code,
we probably should also think expose pathHasWatcher as an API otherwise ZK
users would face similar issue (can't rely on return code, has to use an api
call.).
BTW just for some context info, looks like pathHasWatcher was introduced as
part of ZOOKEEPER-1887.
> C-client crashes when removing watcher asynchronously in "local" mode
> ---------------------------------------------------------------------
>
> Key: ZOOKEEPER-2320
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2320
> Project: ZooKeeper
> Issue Type: Bug
> Components: c client
> Affects Versions: 3.5.1
> Reporter: Hadriel Kaplan
> Assignee: Abraham Fine
> Attachments: ZOOKEEPER-2320.patch
>
>
> The C-client library will crash when invoking the asynchronous
> {{zoo_aremove_watchers()}} API function with the '{{local}}' argument set to
> 1.
> The reason is: if the local argument is 1/true, then the code does
> '{{notify_sync_completion((struct sync_completion *)data);}}' But casting the
> '{{data}}' variable to a {{sync_completion}} struct pointer is bogus/invalid,
> and when it's later handles as that struct pointer it's accessing invalid
> memory.
> As a side note: it will work ok when called _synchronously_ through
> {{zoo_remove_watchers()}}, because that function creates a
> {{sync_completion}} struct and passes it to the asynch
> {{zoo_aremove_watchers()}}, but it will not work ok when the asynch function
> is used directly for the reason stated perviously.
> Another side note: the docs state that setting the 'local' flag makes the
> C-client remove the watcher "even if there is no server connection" - but
> really it makes the C-client remove the watcher without notifying the server
> at *all*, even if the connection to a server is up. (well... that's what it
> would do if it didn't just crash instead ;)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
