ZooKeeper-trunk-openjdk7 - Build # 1659 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-openjdk7/1659/
###
## LAST 60 LINES OF THE CONSOLE
###
[...truncated 66.91 MB...]
[junit] 2017-10-10 23:39:37,269 [myid:] - WARN [New I/O boss
#7359:ClientCnxnSocketNetty$ZKClientHandler@439] - Exception caught: [id:
0x2092315d] EXCEPTION: java.net.ConnectException: Connection refused:
127.0.0.1/127.0.0.1:19365
[junit] java.net.ConnectException: Connection refused:
127.0.0.1/127.0.0.1:19365
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
[junit] at
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
[junit] at
org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
[junit] at
org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
[junit] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:622)
[junit] at java.lang.Thread.run(Thread.java:748)
[junit] 2017-10-10 23:39:37,269 [myid:] - INFO [New I/O boss
#7359:ClientCnxnSocketNetty@208] - channel is told closing
[junit] 2017-10-10 23:39:37,269 [myid:127.0.0.1:19365] - INFO
[main-SendThread(127.0.0.1:19365):ClientCnxn$SendThread@1231] - channel for
sessionid 0x1000fc9eee9 is lost, closing socket connection and attempting
reconnect
[junit] 2017-10-10 23:39:37,285 [myid:127.0.0.1:19350] - INFO
[main-SendThread(127.0.0.1:19350):ClientCnxn$SendThread@1113] - Opening socket
connection to server 127.0.0.1/127.0.0.1:19350. Will not attempt to
authenticate using SASL (unknown error)
[junit] 2017-10-10 23:39:37,286 [myid:] - INFO [New I/O boss
#5049:ClientCnxnSocketNetty$1@127] - future isn't success, cause: {}
[junit] java.net.ConnectException: Connection refused:
127.0.0.1/127.0.0.1:19350
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
[junit] at
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
[junit] at
org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
[junit] at
org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
[junit] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:622)
[junit] at java.lang.Thread.run(Thread.java:748)
[junit] 2017-10-10 23:39:37,286 [myid:] - WARN [New I/O boss
#5049:ClientCnxnSocketNetty$ZKClientHandler@439] - Exception caught: [id:
0x58e405fa] EXCEPTION: java.net.ConnectException: Connection refused:
127.0.0.1/127.0.0.1:19350
[junit] java.net.ConnectException: Connection refused:
127.0.0.1/127.0.0.1:19350
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
[junit] at
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
[junit] at
org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
[junit] at
org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
[junit] at
ZooKeeper_branch35_jdk8 - Build # 711 - Failure
See https://builds.apache.org/job/ZooKeeper_branch35_jdk8/711/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 68.62 MB...] [junit] 2017-10-10 23:28:31,641 [myid:127.0.0.1:11345] - INFO [main-SendThread(127.0.0.1:11345):ClientCnxn$SendThread@1113] - Opening socket connection to server 127.0.0.1/127.0.0.1:11345. Will not attempt to authenticate using SASL (unknown error) [junit] 2017-10-10 23:28:31,642 [myid:127.0.0.1:11345] - WARN [main-SendThread(127.0.0.1:11345):ClientCnxn$SendThread@1235] - Session 0x107327f366b for server 127.0.0.1/127.0.0.1:11345, unexpected error, closing socket connection and attempting reconnect [junit] java.net.ConnectException: Connection refused [junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) [junit] at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717) [junit] at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357) [junit] at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214) [junit] 2017-10-10 23:28:31,934 [myid:127.0.0.1:11271] - INFO [main-SendThread(127.0.0.1:11271):ClientCnxn$SendThread@1113] - Opening socket connection to server 127.0.0.1/127.0.0.1:11271. Will not attempt to authenticate using SASL (unknown error) [junit] 2017-10-10 23:28:31,935 [myid:127.0.0.1:11271] - WARN [main-SendThread(127.0.0.1:11271):ClientCnxn$SendThread@1235] - Session 0x107327c6141 for server 127.0.0.1/127.0.0.1:11271, unexpected error, closing socket connection and attempting reconnect [junit] java.net.ConnectException: Connection refused [junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) [junit] at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717) [junit] at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357) [junit] at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214) [junit] 2017-10-10 23:28:31,949 [myid:127.0.0.1:11222] - INFO [main-SendThread(127.0.0.1:11222):ClientCnxn$SendThread@1113] - Opening socket connection to server 127.0.0.1/127.0.0.1:11222. Will not attempt to authenticate using SASL (unknown error) [junit] 2017-10-10 23:28:31,949 [myid:127.0.0.1:11222] - WARN [main-SendThread(127.0.0.1:11222):ClientCnxn$SendThread@1235] - Session 0x107327c13b2 for server 127.0.0.1/127.0.0.1:11222, unexpected error, closing socket connection and attempting reconnect [junit] java.net.ConnectException: Connection refused [junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) [junit] at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717) [junit] at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357) [junit] at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214) [junit] 2017-10-10 23:28:32,502 [myid:] - INFO [ProcessThread(sid:0 cport:11468)::PrepRequestProcessor@611] - Processed session termination for sessionid: 0x107328267eb [junit] 2017-10-10 23:28:32,503 [myid:] - INFO [SyncThread:0:MBeanRegistry@128] - Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port11468,name1=Connections,name2=127.0.0.1,name3=0x107328267eb] [junit] 2017-10-10 23:28:32,503 [myid:] - INFO [main:ZooKeeper@1334] - Session: 0x107328267eb closed [junit] 2017-10-10 23:28:32,504 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 235161 [junit] 2017-10-10 23:28:32,504 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 2432 [junit] 2017-10-10 23:28:32,504 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD testWatcherAutoResetWithLocal [junit] 2017-10-10 23:28:32,504 [myid:] - INFO [main:ClientBase@586] - tearDown starting [junit] 2017-10-10 23:28:32,503 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for session: 0x107328267eb [junit] 2017-10-10 23:28:32,504 [myid:] - INFO [main:ClientBase@556] - STOPPING server [junit] 2017-10-10 23:28:32,505 [myid:] - INFO [main:NettyServerCnxnFactory@464] - shutdown called 0.0.0.0/0.0.0.0:11468 [junit] 2017-10-10 23:28:32,510 [myid:] - INFO [main:ZooKeeperServer@541] - shutting down [junit] 2017-10-10 23:28:32,510 [myid:] - ERROR [main:ZooKeeperServer@505] - ZKShutdownHandler is not registered, so ZooKeeper server won't take any action on ERROR or SHUTDOWN server state changes [junit] 2017-10-10 23:28:32,511 [myid:] - INFO [main:SessionTrackerImpl@232] - Shutting down [junit] 2017-10-10 23:28:32,511 [myid:] - INFO [main:PrepRequestProcessor@1005] - Shutting down [junit] 2017-10-10
ZooKeeper-trunk - Build # 3572 - Failure
See https://builds.apache.org/job/ZooKeeper-trunk/3572/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 65.56 MB...] [junit] 2017-10-10 23:28:29,270 [myid:] - INFO [QuorumPeer[myid=5](plain=/127.0.0.1:14076)(secure=disabled):Leader@627] - Shutting down [junit] 2017-10-10 23:28:29,270 [myid:] - WARN [QuorumPeer[myid=5](plain=/127.0.0.1:14076)(secure=disabled):QuorumPeer@1161] - PeerState set to LOOKING [junit] 2017-10-10 23:28:29,270 [myid:] - WARN [QuorumPeer[myid=5](plain=/127.0.0.1:14076)(secure=disabled):QuorumPeer@1143] - QuorumPeer main thread exited [junit] 2017-10-10 23:28:29,270 [myid:] - INFO [QuorumPeer[myid=5](plain=/127.0.0.1:14076)(secure=disabled):MBeanRegistry@128] - Unregister MBean [org.apache.ZooKeeperService:name0=ReplicatedServer_id5] [junit] 2017-10-10 23:28:29,270 [myid:] - INFO [QuorumPeer[myid=5](plain=/127.0.0.1:14076)(secure=disabled):MBeanRegistry@128] - Unregister MBean [org.apache.ZooKeeperService:name0=ReplicatedServer_id5,name1=replica.5] [junit] 2017-10-10 23:28:29,270 [myid:] - INFO [QuorumPeer[myid=5](plain=/127.0.0.1:14076)(secure=disabled):MBeanRegistry@128] - Unregister MBean [org.apache.ZooKeeperService:name0=ReplicatedServer_id5,name1=replica.1] [junit] 2017-10-10 23:28:29,270 [myid:] - INFO [QuorumPeer[myid=5](plain=/127.0.0.1:14076)(secure=disabled):MBeanRegistry@128] - Unregister MBean [org.apache.ZooKeeperService:name0=ReplicatedServer_id5,name1=replica.2] [junit] 2017-10-10 23:28:29,271 [myid:] - INFO [QuorumPeer[myid=5](plain=/127.0.0.1:14076)(secure=disabled):MBeanRegistry@128] - Unregister MBean [org.apache.ZooKeeperService:name0=ReplicatedServer_id5,name1=replica.3] [junit] 2017-10-10 23:28:29,269 [myid:] - INFO [/127.0.0.1:14078:QuorumCnxManager$Listener@674] - Leaving listener [junit] 2017-10-10 23:28:29,272 [myid:] - INFO [main:QuorumUtil@254] - Shutting down leader election QuorumPeer[myid=5](plain=/127.0.0.1:14076)(secure=disabled) [junit] 2017-10-10 23:28:29,272 [myid:] - INFO [main:QuorumUtil@259] - Waiting for QuorumPeer[myid=5](plain=/127.0.0.1:14076)(secure=disabled) to exit thread [junit] 2017-10-10 23:28:29,272 [myid:] - INFO [main:FourLetterWordMain@87] - connecting to 127.0.0.1 14064 [junit] 2017-10-10 23:28:29,274 [myid:] - INFO [main:QuorumUtil@243] - 127.0.0.1:14064 is no longer accepting client connections [junit] 2017-10-10 23:28:29,274 [myid:] - INFO [main:FourLetterWordMain@87] - connecting to 127.0.0.1 14067 [junit] 2017-10-10 23:28:29,274 [myid:] - INFO [main:QuorumUtil@243] - 127.0.0.1:14067 is no longer accepting client connections [junit] 2017-10-10 23:28:29,274 [myid:] - INFO [main:FourLetterWordMain@87] - connecting to 127.0.0.1 14070 [junit] 2017-10-10 23:28:29,275 [myid:] - INFO [main:QuorumUtil@243] - 127.0.0.1:14070 is no longer accepting client connections [junit] 2017-10-10 23:28:29,275 [myid:] - INFO [main:FourLetterWordMain@87] - connecting to 127.0.0.1 14073 [junit] 2017-10-10 23:28:29,275 [myid:] - INFO [main:QuorumUtil@243] - 127.0.0.1:14073 is no longer accepting client connections [junit] 2017-10-10 23:28:29,275 [myid:] - INFO [main:FourLetterWordMain@87] - connecting to 127.0.0.1 14076 [junit] 2017-10-10 23:28:29,276 [myid:] - INFO [main:QuorumUtil@243] - 127.0.0.1:14076 is no longer accepting client connections [junit] 2017-10-10 23:28:29,277 [myid:] - INFO [main:ZKTestCase$1@68] - SUCCEEDED testRemoveOneAsynchronous [junit] 2017-10-10 23:28:29,277 [myid:] - INFO [main:ZKTestCase$1@63] - FINISHED testRemoveOneAsynchronous [junit] Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 278.844 sec, Thread: 2, Class: org.apache.zookeeper.test.ReconfigTest [junit] 2017-10-10 23:28:29,513 [myid:] - INFO [WorkerSender[myid=5]:FastLeaderElection$Messenger$WorkerSender@470] - WorkerSender is down [junit] 2017-10-10 23:28:29,514 [myid:] - INFO [WorkerReceiver[myid=5]:FastLeaderElection$Messenger$WorkerReceiver@440] - WorkerReceiver is down [junit] 2017-10-10 23:28:29,519 [myid:] - INFO [WorkerSender[myid=1]:FastLeaderElection$Messenger$WorkerSender@470] - WorkerSender is down [junit] 2017-10-10 23:28:29,520 [myid:] - INFO [WorkerSender[myid=3]:FastLeaderElection$Messenger$WorkerSender@470] - WorkerSender is down [junit] 2017-10-10 23:28:29,520 [myid:] - INFO [WorkerReceiver[myid=1]:FastLeaderElection$Messenger$WorkerReceiver@440] - WorkerReceiver is down [junit] 2017-10-10 23:28:29,520 [myid:] - INFO [WorkerReceiver[myid=3]:FastLeaderElection$Messenger$WorkerReceiver@440] - WorkerReceiver is down [junit] 2017-10-10 23:28:29,520 [myid:] - INFO [WorkerReceiver[myid=4]:FastLeaderElection$Messenger$WorkerReceiver@440] - WorkerReceiver is down [junit] 2017-10-10 23:28:29,521
Meetup at Cloudera
Hello ZooKeeper Community- It has been a while since our last meetup and it would be great to bring everyone together again. Cloudera would be able to host a meetup at our headquarters in Palo Alto, CA next week (I'm thinking 10/19). I was hoping to use the mailing lists to gauge interest. Please reply if you think you would be able to attend or would prefer a different date. Looking forward to hearing from everyone. Thanks, Abe
[jira] [Commented] (ZOOKEEPER-2891) SIGABRT from assert during fake completion on zookeeper_close.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199393#comment-16199393
]
ASF GitHub Bot commented on ZOOKEEPER-2891:
---
Github user phunt commented on the issue:
https://github.com/apache/zookeeper/pull/360
ps. You accidentally included the patch for 2890 in this PR, perhaps you
can fix that at the same time? Thx.
> SIGABRT from assert during fake completion on zookeeper_close.
> --
>
> Key: ZOOKEEPER-2891
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2891
> Project: ZooKeeper
> Issue Type: Bug
> Components: c client
>Affects Versions: 3.4.10
> Environment: Linux ubuntu 4.4.0-87-generic
> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
> https://github.com/apache/zookeeper.git
> branch-3.4
>Reporter: Alexander A. Strelets
>Assignee: Alexander A. Strelets
>Priority: Critical
> Labels: easyfix
> Fix For: 3.4.10
>
>
> ZooKeeper C Client *+single thread+* build
> Function *_deserialize_multi()_* hits *_assert(entry)_* when called for the
> so called "Fake response" which is fabricated by the function
> _free_completions()_ for example when _zookeeper_close()_ is called while
> there is a pending _multi_ request.
> Such fake response includes only the header but zero bytes for the body. Due
> to this {{deserialize_MultiHeader(ia, "multiheader", )}}, which is
> called repeatedly for each {{completion_list_t *entry =
> dequeue_completion(clist)}}, does not assign the _mhdr_ and keeps _mhdr.done
> == 0_ as it was originally initialized. Consequently the _while (!mhdr.done)_
> does not ever end, and finally falls into the _assert(entry)_ with _entry ==
> NULL_ when all sub-requests are "completed". ~// Normally on my platform
> assert raises SIGABRT.~
> I propose to instruct the _deserialize_multi()_ function to break the loop on
> _entry == NULL_ if it was called for an unsuccessfull overal status of the
> multi response, and in particular for the fake response having _ZCLOSING_
> (-116) status. I have introduced the _rc0_ parameter for this.
> *Another issue* with this function is that even if the while-loop exited
> properly, this function returns _rc == 0_, and this return code +overrides+
> the true status value with {{rc = deserialize_multi(xid, cptr, ia, rc)}} in
> the _deserialize_response()_ function. So, the _multi_ response callback
> +handler would be called with _rc == ZOK_ instead of _rc == ZCLOSING_+ which
> is strictly wrong.
> To fix this I propose initializing _rc_ with the introduced _rc0_ instead of
> zero (which is _ZOK_ indeed).
> This is a proposed fix: https://github.com/apache/zookeeper/pull/360
> [upd]
> It looks like about the same problem is described in ZOOKEEPER-1636
> However, the patch proposed in this ticket also remedies the second linked
> problem: reporting ZCLOSING status (as required) to the multi-request
> completion handler.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] zookeeper issue #360: branch-3.4 -- bugfix -- ZOOKEEPER-2891
Github user phunt commented on the issue: https://github.com/apache/zookeeper/pull/360 ps. You accidentally included the patch for 2890 in this PR, perhaps you can fix that at the same time? Thx. ---
[jira] [Commented] (ZOOKEEPER-2891) SIGABRT from assert during fake completion on zookeeper_close.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199391#comment-16199391
]
ASF GitHub Bot commented on ZOOKEEPER-2891:
---
Github user phunt commented on the issue:
https://github.com/apache/zookeeper/pull/360
@xoiss I like this patch but it's missing tests. Can you include the tests
from
https://issues.apache.org/jira/secure/attachment/12671215/ZOOKEEPER-1636.patch
and resubmit?
> SIGABRT from assert during fake completion on zookeeper_close.
> --
>
> Key: ZOOKEEPER-2891
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2891
> Project: ZooKeeper
> Issue Type: Bug
> Components: c client
>Affects Versions: 3.4.10
> Environment: Linux ubuntu 4.4.0-87-generic
> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
> https://github.com/apache/zookeeper.git
> branch-3.4
>Reporter: Alexander A. Strelets
>Assignee: Alexander A. Strelets
>Priority: Critical
> Labels: easyfix
> Fix For: 3.4.10
>
>
> ZooKeeper C Client *+single thread+* build
> Function *_deserialize_multi()_* hits *_assert(entry)_* when called for the
> so called "Fake response" which is fabricated by the function
> _free_completions()_ for example when _zookeeper_close()_ is called while
> there is a pending _multi_ request.
> Such fake response includes only the header but zero bytes for the body. Due
> to this {{deserialize_MultiHeader(ia, "multiheader", )}}, which is
> called repeatedly for each {{completion_list_t *entry =
> dequeue_completion(clist)}}, does not assign the _mhdr_ and keeps _mhdr.done
> == 0_ as it was originally initialized. Consequently the _while (!mhdr.done)_
> does not ever end, and finally falls into the _assert(entry)_ with _entry ==
> NULL_ when all sub-requests are "completed". ~// Normally on my platform
> assert raises SIGABRT.~
> I propose to instruct the _deserialize_multi()_ function to break the loop on
> _entry == NULL_ if it was called for an unsuccessfull overal status of the
> multi response, and in particular for the fake response having _ZCLOSING_
> (-116) status. I have introduced the _rc0_ parameter for this.
> *Another issue* with this function is that even if the while-loop exited
> properly, this function returns _rc == 0_, and this return code +overrides+
> the true status value with {{rc = deserialize_multi(xid, cptr, ia, rc)}} in
> the _deserialize_response()_ function. So, the _multi_ response callback
> +handler would be called with _rc == ZOK_ instead of _rc == ZCLOSING_+ which
> is strictly wrong.
> To fix this I propose initializing _rc_ with the introduced _rc0_ instead of
> zero (which is _ZOK_ indeed).
> This is a proposed fix: https://github.com/apache/zookeeper/pull/360
> [upd]
> It looks like about the same problem is described in ZOOKEEPER-1636
> However, the patch proposed in this ticket also remedies the second linked
> problem: reporting ZCLOSING status (as required) to the multi-request
> completion handler.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] zookeeper issue #360: branch-3.4 -- bugfix -- ZOOKEEPER-2891
Github user phunt commented on the issue: https://github.com/apache/zookeeper/pull/360 @xoiss I like this patch but it's missing tests. Can you include the tests from https://issues.apache.org/jira/secure/attachment/12671215/ZOOKEEPER-1636.patch and resubmit? ---
Success: ZOOKEEPER- PreCommit Build #1097
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1097/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 72.67 MB...] [exec] [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +0 tests included. The patch appears to be a documentation patch that doesn't require tests. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 3.0.1) warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] +1 core tests. The patch passed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1097//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1097//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1097//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Error: No value specified for option "issue" [exec] f39421ae9e15082106eab1d0a860422f4fe82c1e logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] [exec] mv: '/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build/patchprocess' and '/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build/patchprocess' are the same file BUILD SUCCESSFUL Total time: 22 minutes 7 seconds Archiving artifacts Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7 Recording test results Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7 Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7 [description-setter] Description set: ZOOKEEPER-2890 Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7 Email was triggered for: Success Sending email for trigger: Success Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7 Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7 Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7 ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-2915) Use "strict" conflict management in ivy
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199312#comment-16199312 ] Hadoop QA commented on ZOOKEEPER-2915: -- -1 overall. GitHub Pull Request Build +1 @author. The patch does not contain any @author tags. +0 tests included. The patch appears to be a documentation patch that doesn't require tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 3.0.1) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1096//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1096//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1096//console This message is automatically generated. > Use "strict" conflict management in ivy > --- > > Key: ZOOKEEPER-2915 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2915 > Project: ZooKeeper > Issue Type: Improvement >Affects Versions: 3.5.4, 3.6.0, 3.4.11 >Reporter: Abraham Fine >Assignee: Abraham Fine > > Currently it is very difficult to tell exactly which dependencies make it > into the final classpath of zookeeper. We do not perform any conflict > resolution between the test and default classpaths (this has resulted in > strange behavior with the slf4j-log4j12 binding) and have no way of telling > if a change to the dependencies has altered the transitive dependencies > pulled down by the project. > Our dependency list is relatively small so we should use "strict" conflict > management (break the build when we try to pull two versions of the same > dependency) so we can exercise maximum control over the classpath. > Note: I also attempted to find a way to see if I could always prefer > transitive dependencies from the default configuration over those pulled by > the test configuration (to make sure that the zookeeper we test against has > the same dependencies as the one we ship) but this appears to be impossible > (or at least incredibly difficult) with ivy. Any opinions here would be > greatly appreciated. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Failed: ZOOKEEPER- PreCommit Build #1096
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1096/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 28.11 MB...] at hudson.remoting.ChunkedInputStream.read(ChunkedInputStream.java:46) at hudson.remoting.ChunkedInputStream.readUntilBreak(ChunkedInputStream.java:97) at hudson.remoting.ChunkedCommandTransport.readBlock(ChunkedCommandTransport.java:39) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:35) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:59) Caused: java.io.IOException: Backing channel 'H6' is disconnected. at hudson.remoting.RemoteInvocationHandler.channelOrFail(RemoteInvocationHandler.java:192) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:257) at com.sun.proxy.$Proxy140.isAlive(Unknown Source) at hudson.Launcher$RemoteLauncher$ProcImpl.isAlive(Launcher.java:1138) at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:1130) at hudson.tasks.CommandInterpreter.join(CommandInterpreter.java:155) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:109) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:736) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:496) at hudson.model.Run.execute(Run.java:1737) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:419) [exec] [junit] 2017-10-10 20:25:11,666 [myid:] - INFO [main:QuorumUtil@250] - Shutting down quorum peer QuorumPeer[myid=1](plain=/127.0.0.1:24705)(secure=disabled) [exec] [junit] 2017-10-10 20:25:11,667 [myid:] - INFO [main:Follower@200] - shutdown called [exec] [junit] at org.junit.runners.ParentRunner.run(ParentRunner.java:363) [exec] [junit] java.lang.Exception: shutdown Follower [exec] [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:38) [exec] [junit] at org.apache.zookeeper.server.quorum.Follower.shutdown(Follower.java:200) [exec] [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:535) [exec] [junit] at org.apache.zookeeper.server.quorum.QuorumPeer.shutdown(QuorumPeer.java:1187) [exec] [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1182) [exec] [junit] at org.apache.zookeeper.test.QuorumUtil.shutdown(QuorumUtil.java:251) [exec] [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1033) [exec] [junit] at org.apache.zookeeper.test.QuorumUtil.shutdownAll(QuorumUtil.java:238) [exec] [junit] 2017-10-10 20:25:13,728 [myid:] - INFO [main:LearnerZooKeeperServer@165] - Shutting down [exec] [junit] at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncByDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:537) Build step 'Execute shell' marked build as failure ERROR: Step ‘Archive the artifacts’ failed: no workspace for PreCommit-ZOOKEEPER-github-pr-build #1096 ERROR: Step ‘Publish JUnit test result report’ failed: no workspace for PreCommit-ZOOKEEPER-github-pr-build #1096 ERROR: H6 is offline; cannot locate JDK 1.7 (latest) ERROR: H6 is offline; cannot locate JDK 1.7 (latest) Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7 [description-setter] Description set: ZOOKEEPER-2915 Putting comment on the pull request ERROR: H6 is offline; cannot locate JDK 1.7 (latest) ERROR: H6 is offline; cannot locate JDK 1.7 (latest) Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any ERROR: H6 is offline; cannot locate JDK 1.7 (latest) ERROR: H6 is offline; cannot locate JDK 1.7 (latest) Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7 ERROR: H6 is offline; cannot locate JDK 1.7 (latest) ERROR: H6 is offline; cannot locate JDK 1.7 (latest) Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7 ERROR: H6 is offline; cannot locate JDK 1.7 (latest) ERROR: H6 is offline; cannot locate JDK 1.7
[jira] [Commented] (ZOOKEEPER-2890) Local automatic variable is left uninitialized and then freed.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199257#comment-16199257 ] Hudson commented on ZOOKEEPER-2890: --- SUCCESS: Integrated in Jenkins build ZooKeeper-trunk #3571 (See [https://builds.apache.org/job/ZooKeeper-trunk/3571/]) ZOOKEEPER-2890: Local automatic variable is left uninitialized and then (phunt: rev 43a50ebc658dd25b8b9f9f91cf4c32c2c0e3e000) * (edit) src/c/src/zookeeper.c > Local automatic variable is left uninitialized and then freed. > -- > > Key: ZOOKEEPER-2890 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2890 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.10, 3.5.3, 3.6.0 > Environment: Linux ubuntu 4.4.0-87-generic > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 > https://github.com/apache/zookeeper.git > branch-3.4 >Reporter: Alexander A. Strelets >Assignee: Alexander A. Strelets >Priority: Critical > Labels: easyfix > Fix For: 3.5.4, 3.6.0, 3.4.11 > > > ZooKeeper C Client *+single thread+* build > Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local > automatic variable *_struct CreateResponse res_* which is +left > uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and > then to _deallocate_GetACLResponse()_. > The _deserialize_ function, which is called the first, is expected to assign > the _res_ variable with a value from the parsed _struct iarchive *ia_. But, > if _ia_ contains for example insufficient amount of bytes the > _deserialize_String()_ function refuses of assigning a value to _res_, and > _res_ stays uninitialized (the true case is described below). Then, the > _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ > with arguments. If incidentally the memory region in the program stack under > the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid > address+. > The true case: this happens when an active _multi_ request with _create_ > sub-request is completed on call to _zookeeper_close()_ with the so called > "Fake response" which is fabricated by the function _free_completions()_. > Such response includes only the header but +zero bytes for the body+. The > significant condition is that the _create_ request is not a stand-alone one, > but namely a sub-request within the _multi_ request. In this case the > _deserialize_response()_ is called recursively (for each sub-request), and > when it is called for the _create_ subrequest (from the nested > _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so > the _if (failed)_ condition branches to the _else_ part. Note that in the > stand-alone create-request case this does not occur. > *I suspect this may happen not only due to call to _zookeeper_close()_ but on > reception of a true multi-response from the server* containing insufficient > number of bytes (I'm not sure if it can be a proper response from the server > with an error overall status and empty or insufficient payload). > This is a proposed fix: https://github.com/apache/zookeeper/pull/359 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ZOOKEEPER-2915) Use "strict" conflict management in ivy
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199246#comment-16199246 ] ASF GitHub Bot commented on ZOOKEEPER-2915: --- Github user afine commented on the issue: https://github.com/apache/zookeeper/pull/396 @phunt Egah. This patch is correct and I fixed the other one (the one based on master). The end result of this patch should be, when running the tests, all dependencies from ivy should be available in one directory (build/test/lib) and build/lib should NOT be in the classpath. > Use "strict" conflict management in ivy > --- > > Key: ZOOKEEPER-2915 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2915 > Project: ZooKeeper > Issue Type: Improvement >Affects Versions: 3.5.4, 3.6.0, 3.4.11 >Reporter: Abraham Fine >Assignee: Abraham Fine > > Currently it is very difficult to tell exactly which dependencies make it > into the final classpath of zookeeper. We do not perform any conflict > resolution between the test and default classpaths (this has resulted in > strange behavior with the slf4j-log4j12 binding) and have no way of telling > if a change to the dependencies has altered the transitive dependencies > pulled down by the project. > Our dependency list is relatively small so we should use "strict" conflict > management (break the build when we try to pull two versions of the same > dependency) so we can exercise maximum control over the classpath. > Note: I also attempted to find a way to see if I could always prefer > transitive dependencies from the default configuration over those pulled by > the test configuration (to make sure that the zookeeper we test against has > the same dependencies as the one we ship) but this appears to be impossible > (or at least incredibly difficult) with ivy. Any opinions here would be > greatly appreciated. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] zookeeper issue #396: ZOOKEEPER-2915: Use "strict" conflict management in iv...
Github user afine commented on the issue: https://github.com/apache/zookeeper/pull/396 @phunt Egah. This patch is correct and I fixed the other one (the one based on master). The end result of this patch should be, when running the tests, all dependencies from ivy should be available in one directory (build/test/lib) and build/lib should NOT be in the classpath. ---
ZooKeeper-trunk-openjdk7 - Build # 1658 - Failure
See https://builds.apache.org/job/ZooKeeper-trunk-openjdk7/1658/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 69.18 MB...] [junit] 2017-10-10 19:14:38,835 [myid:127.0.0.1:11228] - INFO [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1229] - Client session timed out, have not heard from server in 30014ms for sessionid 0x0, closing socket connection and attempting reconnect [junit] 2017-10-10 19:14:40,750 [myid:127.0.0.1:11228] - INFO [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1113] - Opening socket connection to server 127.0.0.1/127.0.0.1:11228. Will not attempt to authenticate using SASL (unknown error) [junit] 2017-10-10 19:14:40,752 [myid:2] - INFO [NIOServerCxnFactory.AcceptThread:localhost/127.0.0.1:11228:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:32954 [junit] 2017-10-10 19:14:40,752 [myid:127.0.0.1:11228] - INFO [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@946] - Socket connection established, initiating session, client: /127.0.0.1:32954, server: 127.0.0.1/127.0.0.1:11228 [junit] 2017-10-10 19:14:50,994 [myid:127.0.0.1:11228] - WARN [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1181] - Client session timed out, have not heard from server in 30021ms for sessionid 0x203f6a6b23a [junit] 2017-10-10 19:14:50,995 [myid:127.0.0.1:11228] - INFO [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1229] - Client session timed out, have not heard from server in 30021ms for sessionid 0x203f6a6b23a, closing socket connection and attempting reconnect [junit] 2017-10-10 19:14:52,897 [myid:127.0.0.1:11228] - INFO [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1113] - Opening socket connection to server 127.0.0.1/127.0.0.1:11228. Will not attempt to authenticate using SASL (unknown error) [junit] 2017-10-10 19:14:52,898 [myid:127.0.0.1:11228] - INFO [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@946] - Socket connection established, initiating session, client: /127.0.0.1:33078, server: 127.0.0.1/127.0.0.1:11228 [junit] 2017-10-10 19:14:52,898 [myid:2] - INFO [NIOServerCxnFactory.AcceptThread:localhost/127.0.0.1:11228:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:33078 [junit] 2017-10-10 19:15:10,780 [myid:127.0.0.1:11228] - WARN [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1181] - Client session timed out, have not heard from server in 30028ms for sessionid 0x0 [junit] 2017-10-10 19:15:10,780 [myid:127.0.0.1:11228] - INFO [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1229] - Client session timed out, have not heard from server in 30028ms for sessionid 0x0, closing socket connection and attempting reconnect [junit] 2017-10-10 19:15:12,186 [myid:127.0.0.1:11228] - INFO [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1113] - Opening socket connection to server 127.0.0.1/127.0.0.1:11228. Will not attempt to authenticate using SASL (unknown error) [junit] 2017-10-10 19:15:12,187 [myid:127.0.0.1:11228] - INFO [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@946] - Socket connection established, initiating session, client: /127.0.0.1:33277, server: 127.0.0.1/127.0.0.1:11228 [junit] 2017-10-10 19:15:12,187 [myid:2] - INFO [NIOServerCxnFactory.AcceptThread:localhost/127.0.0.1:11228:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:33277 [junit] 2017-10-10 19:15:22,927 [myid:127.0.0.1:11228] - WARN [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1181] - Client session timed out, have not heard from server in 30029ms for sessionid 0x203f6a6b23a [junit] 2017-10-10 19:15:22,928 [myid:127.0.0.1:11228] - INFO [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1229] - Client session timed out, have not heard from server in 30029ms for sessionid 0x203f6a6b23a, closing socket connection and attempting reconnect [junit] 2017-10-10 19:15:24,472 [myid:127.0.0.1:11228] - INFO [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1113] - Opening socket connection to server 127.0.0.1/127.0.0.1:11228. Will not attempt to authenticate using SASL (unknown error) [junit] 2017-10-10 19:15:24,473 [myid:127.0.0.1:11228] - INFO [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@946] - Socket connection established, initiating session, client: /127.0.0.1:33406, server: 127.0.0.1/127.0.0.1:11228 [junit] 2017-10-10 19:15:24,473 [myid:2] - INFO [NIOServerCxnFactory.AcceptThread:localhost/127.0.0.1:11228:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:33406 [junit] 2017-10-10 19:15:42,196 [myid:127.0.0.1:11228] - WARN [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1181] - Client
[jira] [Commented] (ZOOKEEPER-2890) Local automatic variable is left uninitialized and then freed.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199181#comment-16199181 ] ASF GitHub Bot commented on ZOOKEEPER-2890: --- Github user phunt commented on the issue: https://github.com/apache/zookeeper/pull/359 Thanks @xoiss ! > Local automatic variable is left uninitialized and then freed. > -- > > Key: ZOOKEEPER-2890 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2890 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.10, 3.5.3, 3.6.0 > Environment: Linux ubuntu 4.4.0-87-generic > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 > https://github.com/apache/zookeeper.git > branch-3.4 >Reporter: Alexander A. Strelets >Assignee: Alexander A. Strelets >Priority: Critical > Labels: easyfix > Fix For: 3.5.4, 3.6.0, 3.4.11 > > > ZooKeeper C Client *+single thread+* build > Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local > automatic variable *_struct CreateResponse res_* which is +left > uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and > then to _deallocate_GetACLResponse()_. > The _deserialize_ function, which is called the first, is expected to assign > the _res_ variable with a value from the parsed _struct iarchive *ia_. But, > if _ia_ contains for example insufficient amount of bytes the > _deserialize_String()_ function refuses of assigning a value to _res_, and > _res_ stays uninitialized (the true case is described below). Then, the > _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ > with arguments. If incidentally the memory region in the program stack under > the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid > address+. > The true case: this happens when an active _multi_ request with _create_ > sub-request is completed on call to _zookeeper_close()_ with the so called > "Fake response" which is fabricated by the function _free_completions()_. > Such response includes only the header but +zero bytes for the body+. The > significant condition is that the _create_ request is not a stand-alone one, > but namely a sub-request within the _multi_ request. In this case the > _deserialize_response()_ is called recursively (for each sub-request), and > when it is called for the _create_ subrequest (from the nested > _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so > the _if (failed)_ condition branches to the _else_ part. Note that in the > stand-alone create-request case this does not occur. > *I suspect this may happen not only due to call to _zookeeper_close()_ but on > reception of a true multi-response from the server* containing insufficient > number of bytes (I'm not sure if it can be a proper response from the server > with an error overall status and empty or insufficient payload). > This is a proposed fix: https://github.com/apache/zookeeper/pull/359 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] zookeeper issue #359: branch-3.4 -- bugfix -- ZOOKEEPER-2890
Github user phunt commented on the issue: https://github.com/apache/zookeeper/pull/359 Thanks @xoiss ! ---
[jira] [Assigned] (ZOOKEEPER-2894) Memory and completions leak on zookeeper_close.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt reassigned ZOOKEEPER-2894: --- Assignee: Alexander A. Strelets > Memory and completions leak on zookeeper_close. > --- > > Key: ZOOKEEPER-2894 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2894 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.10 > Environment: Linux ubuntu 4.4.0-87-generic > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 > https://github.com/apache/zookeeper.git > branch-3.4 >Reporter: Alexander A. Strelets >Assignee: Alexander A. Strelets >Priority: Critical > Labels: easyfix > Fix For: 3.4.10 > > Attachments: zk-will-free-zh-and-lose-completions.png > > > ZooKeeper C Client *+single thread+* build > First of all, ZooKeeper C Client design allows calling _zookeeper_close()_ in > two ways: > a) from a ZooKeeper callback handler (completion or watcher) which in turn is > called through _zookeeper_process()_ > b) and from other places -- i.e., when the call-stack does not pass through > any of zookeeper mechanics prior to enter into mentioned _zookeeper_close()_ > The issue described here below is +specific only to the case (b)+. So, it's > Ok with the case (a). > When _zookeeper_close()_ is called in the (b) way, the following happens: > 1. +If there are requests waiting for responses in _zh.sent_requests_ queue+, > they all are removed from this queue and each of them is "completed" with > personal fake response having status ZCLOSING. Such fake responses are put > into _zh.completions_to_process_ queue. It's Ok > 2. But then, _zh.completions_to_process_ queue is left unhandled. +Neither > completion callbacks are called, nor dynamic memory allocated for fake > responses is freed+ > 3. Different structures within _zh_ are dismissed and finally _zh_ is freed > This is illustrated on the screenshot attached to this ticket: you may see > that the next instruction to execute will be _free(zh)_ while > _zh.completions_to_process_ queue is not empty (see the "Variables" tab to > the right). > Alternatively, the same situation but in the case (a) is handled properly -- > i.e., all completion callback handlers are truly called with ZCLOSING and the > memory is freed, both for subcases (a.1) when there is a failure like > connection-timeout, connection-closed, etc., or (a.2) there is not failure. > The reason is that any callback handler (completion or watcher) in the case > (a) is called from the _process_completions()_ function which runs in the > loop until _zh.completions_to_process_ queue gets empty. So, this function > guarantees this queue to be completely processed even if new completions > occur during reaction on previously queued completions. > *Consequently:* > 1. At least there is definitely the +memory leak+ in the case (b) -- all the > fake responses put into _zh.completions_to_process_ queue are lost after > _free(zh)_ > 2. And it looks like a great misbehavior not to call completions on sent > requests in the case (b) while they are called with ZCLOSING in the case (a) > -- so, I think it's not "by design" but a +completions leak+ > +To reproduce the case (b) do the following:+ > - open ZooKeeper session, connect to a server, receive and process > connected-watch, etc. > - then somewhere +from the main events loop+ call for example _zoo_acreate()_ > with valid arguments -- it shall return ZOK > - then, +immediately after it returned+, call _zookeeper_close()_ > - note that completion callback handler for _zoo_acreate()_ *will not be > called* > +To reproduce the case (a) do the following:+ > - the same as above, open ZooKeeper session, connect to a server, receive and > process connected-watch, etc. > - the same as above, somewhere from the main events loop call for example > _zoo_acreate()_ with valid arguments -- it shall return ZOK > - but now don't call _zookeeper_close()_ immediately -- wait for completion > callback on the commenced request > - when _zoo_acreate()_ completes, +from within its completion callback > handler+, call another _zoo_acreate()_ and immediately after it returned call > _zookeeper_close()_ > - note that completion callback handler for the second _zoo_acreate()_ *will > be called with ZCLOSING, unlike the case (b) described above* > To fix this I propose calling to _process_completions()_ from > _destroy(zhandle_t *zh)_ as it is done in _handle_error(zhandle_t *zh,int > rc)_. > This is a proposed fix: https://github.com/apache/zookeeper/pull/363 > [upd] > There are another tickets with about the same problem: ZOOKEEPER-1493, > ZOOKEEPER-2073 (the "same" just according to their titles). > However, as I
[jira] [Assigned] (ZOOKEEPER-2891) SIGABRT from assert during fake completion on zookeeper_close.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Hunt reassigned ZOOKEEPER-2891:
---
Assignee: Alexander A. Strelets
> SIGABRT from assert during fake completion on zookeeper_close.
> --
>
> Key: ZOOKEEPER-2891
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2891
> Project: ZooKeeper
> Issue Type: Bug
> Components: c client
>Affects Versions: 3.4.10
> Environment: Linux ubuntu 4.4.0-87-generic
> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
> https://github.com/apache/zookeeper.git
> branch-3.4
>Reporter: Alexander A. Strelets
>Assignee: Alexander A. Strelets
>Priority: Critical
> Labels: easyfix
> Fix For: 3.4.10
>
>
> ZooKeeper C Client *+single thread+* build
> Function *_deserialize_multi()_* hits *_assert(entry)_* when called for the
> so called "Fake response" which is fabricated by the function
> _free_completions()_ for example when _zookeeper_close()_ is called while
> there is a pending _multi_ request.
> Such fake response includes only the header but zero bytes for the body. Due
> to this {{deserialize_MultiHeader(ia, "multiheader", )}}, which is
> called repeatedly for each {{completion_list_t *entry =
> dequeue_completion(clist)}}, does not assign the _mhdr_ and keeps _mhdr.done
> == 0_ as it was originally initialized. Consequently the _while (!mhdr.done)_
> does not ever end, and finally falls into the _assert(entry)_ with _entry ==
> NULL_ when all sub-requests are "completed". ~// Normally on my platform
> assert raises SIGABRT.~
> I propose to instruct the _deserialize_multi()_ function to break the loop on
> _entry == NULL_ if it was called for an unsuccessfull overal status of the
> multi response, and in particular for the fake response having _ZCLOSING_
> (-116) status. I have introduced the _rc0_ parameter for this.
> *Another issue* with this function is that even if the while-loop exited
> properly, this function returns _rc == 0_, and this return code +overrides+
> the true status value with {{rc = deserialize_multi(xid, cptr, ia, rc)}} in
> the _deserialize_response()_ function. So, the _multi_ response callback
> +handler would be called with _rc == ZOK_ instead of _rc == ZCLOSING_+ which
> is strictly wrong.
> To fix this I propose initializing _rc_ with the introduced _rc0_ instead of
> zero (which is _ZOK_ indeed).
> This is a proposed fix: https://github.com/apache/zookeeper/pull/360
> [upd]
> It looks like about the same problem is described in ZOOKEEPER-1636
> However, the patch proposed in this ticket also remedies the second linked
> problem: reporting ZCLOSING status (as required) to the multi-request
> completion handler.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (ZOOKEEPER-2890) Local automatic variable is left uninitialized and then freed.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt reassigned ZOOKEEPER-2890: --- Assignee: Alexander A. Strelets > Local automatic variable is left uninitialized and then freed. > -- > > Key: ZOOKEEPER-2890 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2890 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.10, 3.5.3, 3.6.0 > Environment: Linux ubuntu 4.4.0-87-generic > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 > https://github.com/apache/zookeeper.git > branch-3.4 >Reporter: Alexander A. Strelets >Assignee: Alexander A. Strelets >Priority: Critical > Labels: easyfix > Fix For: 3.5.4, 3.6.0, 3.4.11 > > > ZooKeeper C Client *+single thread+* build > Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local > automatic variable *_struct CreateResponse res_* which is +left > uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and > then to _deallocate_GetACLResponse()_. > The _deserialize_ function, which is called the first, is expected to assign > the _res_ variable with a value from the parsed _struct iarchive *ia_. But, > if _ia_ contains for example insufficient amount of bytes the > _deserialize_String()_ function refuses of assigning a value to _res_, and > _res_ stays uninitialized (the true case is described below). Then, the > _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ > with arguments. If incidentally the memory region in the program stack under > the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid > address+. > The true case: this happens when an active _multi_ request with _create_ > sub-request is completed on call to _zookeeper_close()_ with the so called > "Fake response" which is fabricated by the function _free_completions()_. > Such response includes only the header but +zero bytes for the body+. The > significant condition is that the _create_ request is not a stand-alone one, > but namely a sub-request within the _multi_ request. In this case the > _deserialize_response()_ is called recursively (for each sub-request), and > when it is called for the _create_ subrequest (from the nested > _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so > the _if (failed)_ condition branches to the _else_ part. Note that in the > stand-alone create-request case this does not occur. > *I suspect this may happen not only due to call to _zookeeper_close()_ but on > reception of a true multi-response from the server* containing insufficient > number of bytes (I'm not sure if it can be a proper response from the server > with an error overall status and empty or insufficient payload). > This is a proposed fix: https://github.com/apache/zookeeper/pull/359 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ZOOKEEPER-2890) Local automatic variable is left uninitialized and then freed.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt resolved ZOOKEEPER-2890. - Resolution: Fixed Issue resolved by pull request 359 [https://github.com/apache/zookeeper/pull/359] > Local automatic variable is left uninitialized and then freed. > -- > > Key: ZOOKEEPER-2890 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2890 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.10, 3.5.3, 3.6.0 > Environment: Linux ubuntu 4.4.0-87-generic > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 > https://github.com/apache/zookeeper.git > branch-3.4 >Reporter: Alexander A. Strelets >Priority: Critical > Labels: easyfix > Fix For: 3.4.11, 3.6.0, 3.5.4 > > > ZooKeeper C Client *+single thread+* build > Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local > automatic variable *_struct CreateResponse res_* which is +left > uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and > then to _deallocate_GetACLResponse()_. > The _deserialize_ function, which is called the first, is expected to assign > the _res_ variable with a value from the parsed _struct iarchive *ia_. But, > if _ia_ contains for example insufficient amount of bytes the > _deserialize_String()_ function refuses of assigning a value to _res_, and > _res_ stays uninitialized (the true case is described below). Then, the > _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ > with arguments. If incidentally the memory region in the program stack under > the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid > address+. > The true case: this happens when an active _multi_ request with _create_ > sub-request is completed on call to _zookeeper_close()_ with the so called > "Fake response" which is fabricated by the function _free_completions()_. > Such response includes only the header but +zero bytes for the body+. The > significant condition is that the _create_ request is not a stand-alone one, > but namely a sub-request within the _multi_ request. In this case the > _deserialize_response()_ is called recursively (for each sub-request), and > when it is called for the _create_ subrequest (from the nested > _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so > the _if (failed)_ condition branches to the _else_ part. Note that in the > stand-alone create-request case this does not occur. > *I suspect this may happen not only due to call to _zookeeper_close()_ but on > reception of a true multi-response from the server* containing insufficient > number of bytes (I'm not sure if it can be a proper response from the server > with an error overall status and empty or insufficient payload). > This is a proposed fix: https://github.com/apache/zookeeper/pull/359 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ZOOKEEPER-2890) Local automatic variable is left uninitialized and then freed.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199172#comment-16199172 ] ASF GitHub Bot commented on ZOOKEEPER-2890: --- Github user asfgit closed the pull request at: https://github.com/apache/zookeeper/pull/359 > Local automatic variable is left uninitialized and then freed. > -- > > Key: ZOOKEEPER-2890 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2890 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.10, 3.5.3, 3.6.0 > Environment: Linux ubuntu 4.4.0-87-generic > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 > https://github.com/apache/zookeeper.git > branch-3.4 >Reporter: Alexander A. Strelets >Priority: Critical > Labels: easyfix > Fix For: 3.5.4, 3.6.0, 3.4.11 > > > ZooKeeper C Client *+single thread+* build > Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local > automatic variable *_struct CreateResponse res_* which is +left > uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and > then to _deallocate_GetACLResponse()_. > The _deserialize_ function, which is called the first, is expected to assign > the _res_ variable with a value from the parsed _struct iarchive *ia_. But, > if _ia_ contains for example insufficient amount of bytes the > _deserialize_String()_ function refuses of assigning a value to _res_, and > _res_ stays uninitialized (the true case is described below). Then, the > _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ > with arguments. If incidentally the memory region in the program stack under > the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid > address+. > The true case: this happens when an active _multi_ request with _create_ > sub-request is completed on call to _zookeeper_close()_ with the so called > "Fake response" which is fabricated by the function _free_completions()_. > Such response includes only the header but +zero bytes for the body+. The > significant condition is that the _create_ request is not a stand-alone one, > but namely a sub-request within the _multi_ request. In this case the > _deserialize_response()_ is called recursively (for each sub-request), and > when it is called for the _create_ subrequest (from the nested > _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so > the _if (failed)_ condition branches to the _else_ part. Note that in the > stand-alone create-request case this does not occur. > *I suspect this may happen not only due to call to _zookeeper_close()_ but on > reception of a true multi-response from the server* containing insufficient > number of bytes (I'm not sure if it can be a proper response from the server > with an error overall status and empty or insufficient payload). > This is a proposed fix: https://github.com/apache/zookeeper/pull/359 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] zookeeper pull request #359: branch-3.4 -- bugfix -- ZOOKEEPER-2890
Github user asfgit closed the pull request at: https://github.com/apache/zookeeper/pull/359 ---
[jira] [Commented] (ZOOKEEPER-2908) quorum.auth.MiniKdcTest.testKerberosLogin failing with NPE on java 9
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199161#comment-16199161
]
ASF GitHub Bot commented on ZOOKEEPER-2908:
---
Github user mfenes closed the pull request at:
https://github.com/apache/zookeeper/pull/390
> quorum.auth.MiniKdcTest.testKerberosLogin failing with NPE on java 9
>
>
> Key: ZOOKEEPER-2908
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2908
> Project: ZooKeeper
> Issue Type: Bug
> Components: security, tests
>Affects Versions: 3.5.4, 3.4.11
>Reporter: Patrick Hunt
>Assignee: Mark Fenes
>Priority: Blocker
> Fix For: 3.5.4, 3.4.11
>
>
> quorum.auth.MiniKdcTest.testKerberosLogin is failing with an NPE on Java 9.
> I recently setup jenkins jobs for java 9 on branch 3.4 and 3.5 and the test
> is failing as follows.
> {noformat}
> javax.security.auth.login.LoginException: java.lang.NullPointerException:
> invalid null input(s)
> at java.base/java.util.Objects.requireNonNull(Objects.java:246)
> at
> java.base/javax.security.auth.Subject$SecureSet.remove(Subject.java:1172)
> at
> java.base/java.util.Collections$SynchronizedCollection.remove(Collections.java:2039)
> at
> jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.logout(Krb5LoginModule.java:1193)
> at
> java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:732)
> at
> java.base/javax.security.auth.login.LoginContext.access$000(LoginContext.java:194)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> at
> java.base/javax.security.auth.login.LoginContext.logout(LoginContext.java:613)
> at
> org.apache.zookeeper.server.quorum.auth.MiniKdcTest.testKerberosLogin(MiniKdcTest.java:179)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:55)
> at
> java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:821)
> at
> java.base/javax.security.auth.login.LoginContext.access$000(LoginContext.java:194)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> at
> java.base/javax.security.auth.login.LoginContext.logout(LoginContext.java:613)
> at
> org.apache.zookeeper.server.quorum.auth.MiniKdcTest.testKerberosLogin(MiniKdcTest.java:179)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:55)
> {noformat}
> https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper_branch34_java9/1/testReport/junit/org.apache.zookeeper.server.quorum.auth/MiniKdcTest/testKerberosLogin/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] zookeeper pull request #390: ZOOKEEPER-2908: quorum.auth.MiniKdcTest.testKer...
Github user mfenes closed the pull request at: https://github.com/apache/zookeeper/pull/390 ---
[jira] [Updated] (ZOOKEEPER-2890) Local automatic variable is left uninitialized and then freed.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-2890: Fix Version/s: (was: 3.4.10) 3.4.11 3.6.0 3.5.4 > Local automatic variable is left uninitialized and then freed. > -- > > Key: ZOOKEEPER-2890 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2890 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.10, 3.5.3, 3.6.0 > Environment: Linux ubuntu 4.4.0-87-generic > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 > https://github.com/apache/zookeeper.git > branch-3.4 >Reporter: Alexander A. Strelets >Priority: Critical > Labels: easyfix > Fix For: 3.5.4, 3.6.0, 3.4.11 > > > ZooKeeper C Client *+single thread+* build > Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local > automatic variable *_struct CreateResponse res_* which is +left > uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and > then to _deallocate_GetACLResponse()_. > The _deserialize_ function, which is called the first, is expected to assign > the _res_ variable with a value from the parsed _struct iarchive *ia_. But, > if _ia_ contains for example insufficient amount of bytes the > _deserialize_String()_ function refuses of assigning a value to _res_, and > _res_ stays uninitialized (the true case is described below). Then, the > _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ > with arguments. If incidentally the memory region in the program stack under > the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid > address+. > The true case: this happens when an active _multi_ request with _create_ > sub-request is completed on call to _zookeeper_close()_ with the so called > "Fake response" which is fabricated by the function _free_completions()_. > Such response includes only the header but +zero bytes for the body+. The > significant condition is that the _create_ request is not a stand-alone one, > but namely a sub-request within the _multi_ request. In this case the > _deserialize_response()_ is called recursively (for each sub-request), and > when it is called for the _create_ subrequest (from the nested > _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so > the _if (failed)_ condition branches to the _else_ part. Note that in the > stand-alone create-request case this does not occur. > *I suspect this may happen not only due to call to _zookeeper_close()_ but on > reception of a true multi-response from the server* containing insufficient > number of bytes (I'm not sure if it can be a proper response from the server > with an error overall status and empty or insufficient payload). > This is a proposed fix: https://github.com/apache/zookeeper/pull/359 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ZOOKEEPER-2890) Local automatic variable is left uninitialized and then freed.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-2890: Affects Version/s: 3.6.0 3.5.3 > Local automatic variable is left uninitialized and then freed. > -- > > Key: ZOOKEEPER-2890 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2890 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.10, 3.5.3, 3.6.0 > Environment: Linux ubuntu 4.4.0-87-generic > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 > https://github.com/apache/zookeeper.git > branch-3.4 >Reporter: Alexander A. Strelets >Priority: Critical > Labels: easyfix > Fix For: 3.5.4, 3.6.0, 3.4.11 > > > ZooKeeper C Client *+single thread+* build > Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local > automatic variable *_struct CreateResponse res_* which is +left > uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and > then to _deallocate_GetACLResponse()_. > The _deserialize_ function, which is called the first, is expected to assign > the _res_ variable with a value from the parsed _struct iarchive *ia_. But, > if _ia_ contains for example insufficient amount of bytes the > _deserialize_String()_ function refuses of assigning a value to _res_, and > _res_ stays uninitialized (the true case is described below). Then, the > _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ > with arguments. If incidentally the memory region in the program stack under > the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid > address+. > The true case: this happens when an active _multi_ request with _create_ > sub-request is completed on call to _zookeeper_close()_ with the so called > "Fake response" which is fabricated by the function _free_completions()_. > Such response includes only the header but +zero bytes for the body+. The > significant condition is that the _create_ request is not a stand-alone one, > but namely a sub-request within the _multi_ request. In this case the > _deserialize_response()_ is called recursively (for each sub-request), and > when it is called for the _create_ subrequest (from the nested > _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so > the _if (failed)_ condition branches to the _else_ part. Note that in the > stand-alone create-request case this does not occur. > *I suspect this may happen not only due to call to _zookeeper_close()_ but on > reception of a true multi-response from the server* containing insufficient > number of bytes (I'm not sure if it can be a proper response from the server > with an error overall status and empty or insufficient payload). > This is a proposed fix: https://github.com/apache/zookeeper/pull/359 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ZOOKEEPER-2908) quorum.auth.MiniKdcTest.testKerberosLogin failing with NPE on java 9
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199136#comment-16199136
]
ASF GitHub Bot commented on ZOOKEEPER-2908:
---
Github user phunt commented on the issue:
https://github.com/apache/zookeeper/pull/390
@mfenes please close this.
> quorum.auth.MiniKdcTest.testKerberosLogin failing with NPE on java 9
>
>
> Key: ZOOKEEPER-2908
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2908
> Project: ZooKeeper
> Issue Type: Bug
> Components: security, tests
>Affects Versions: 3.5.4, 3.4.11
>Reporter: Patrick Hunt
>Assignee: Mark Fenes
>Priority: Blocker
> Fix For: 3.5.4, 3.4.11
>
>
> quorum.auth.MiniKdcTest.testKerberosLogin is failing with an NPE on Java 9.
> I recently setup jenkins jobs for java 9 on branch 3.4 and 3.5 and the test
> is failing as follows.
> {noformat}
> javax.security.auth.login.LoginException: java.lang.NullPointerException:
> invalid null input(s)
> at java.base/java.util.Objects.requireNonNull(Objects.java:246)
> at
> java.base/javax.security.auth.Subject$SecureSet.remove(Subject.java:1172)
> at
> java.base/java.util.Collections$SynchronizedCollection.remove(Collections.java:2039)
> at
> jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.logout(Krb5LoginModule.java:1193)
> at
> java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:732)
> at
> java.base/javax.security.auth.login.LoginContext.access$000(LoginContext.java:194)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> at
> java.base/javax.security.auth.login.LoginContext.logout(LoginContext.java:613)
> at
> org.apache.zookeeper.server.quorum.auth.MiniKdcTest.testKerberosLogin(MiniKdcTest.java:179)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:55)
> at
> java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:821)
> at
> java.base/javax.security.auth.login.LoginContext.access$000(LoginContext.java:194)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> at
> java.base/javax.security.auth.login.LoginContext.logout(LoginContext.java:613)
> at
> org.apache.zookeeper.server.quorum.auth.MiniKdcTest.testKerberosLogin(MiniKdcTest.java:179)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:55)
> {noformat}
> https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper_branch34_java9/1/testReport/junit/org.apache.zookeeper.server.quorum.auth/MiniKdcTest/testKerberosLogin/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] zookeeper issue #390: ZOOKEEPER-2908: quorum.auth.MiniKdcTest.testKerberosLo...
Github user phunt commented on the issue: https://github.com/apache/zookeeper/pull/390 @mfenes please close this. ---
[jira] [Commented] (ZOOKEEPER-2915) Use "strict" conflict management in ivy
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199133#comment-16199133 ] ASF GitHub Bot commented on ZOOKEEPER-2915: --- Github user phunt commented on the issue: https://github.com/apache/zookeeper/pull/396 @afine something seems wrong with this patch compared to master patch #397 On master there are no dup'd libraries in build/test/lib after "ant clean compile-test" - in this patch (3.4) I see many of the main libs dup'd into build/test/lib. Can you LMK what's what? > Use "strict" conflict management in ivy > --- > > Key: ZOOKEEPER-2915 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2915 > Project: ZooKeeper > Issue Type: Improvement >Affects Versions: 3.5.4, 3.6.0, 3.4.11 >Reporter: Abraham Fine >Assignee: Abraham Fine > > Currently it is very difficult to tell exactly which dependencies make it > into the final classpath of zookeeper. We do not perform any conflict > resolution between the test and default classpaths (this has resulted in > strange behavior with the slf4j-log4j12 binding) and have no way of telling > if a change to the dependencies has altered the transitive dependencies > pulled down by the project. > Our dependency list is relatively small so we should use "strict" conflict > management (break the build when we try to pull two versions of the same > dependency) so we can exercise maximum control over the classpath. > Note: I also attempted to find a way to see if I could always prefer > transitive dependencies from the default configuration over those pulled by > the test configuration (to make sure that the zookeeper we test against has > the same dependencies as the one we ship) but this appears to be impossible > (or at least incredibly difficult) with ivy. Any opinions here would be > greatly appreciated. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] zookeeper issue #396: ZOOKEEPER-2915: Use "strict" conflict management in iv...
Github user phunt commented on the issue: https://github.com/apache/zookeeper/pull/396 @afine something seems wrong with this patch compared to master patch #397 On master there are no dup'd libraries in build/test/lib after "ant clean compile-test" - in this patch (3.4) I see many of the main libs dup'd into build/test/lib. Can you LMK what's what? ---
[jira] [Commented] (ZOOKEEPER-2357) Unhandled errors propagating through cluster
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199059#comment-16199059 ] Srihari Thathineni commented on ZOOKEEPER-2357: --- We are also seeing this issue recently with Zookeeper 3.4.6 > Unhandled errors propagating through cluster > > > Key: ZOOKEEPER-2357 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2357 > Project: ZooKeeper > Issue Type: Task > Components: leaderElection, quorum, server >Affects Versions: 3.4.6 >Reporter: Gareth Humphries >Priority: Minor > > Hi, > I need some help understanding a recurring problem we're seeing with our > zookeeper cluster. It's a five node cluster that ordinarily runs fine. > Occasionally we see an error from which the cluster recovers, but it causes a > lot of grief and I'm sure is representative of an unhealthy situation. > To my eye it looks like an invalid bit of data getting into the system and > not being handled gracefully; I'm the first to say my eye is not expert > though, so I humbly submit an annotated log exert in the hope some who knows > more than me can provide some illumination. > The cluster seems to be ticking along fine, until we get errors on 2 of the 5 > nodes like so: > 2016-01-19 13:12:49,698 - WARN [QuorumPeer[myid=1]/0.0.0.0:2181:Follower@89] > - Exception when following the leader > java.io.EOFException > at java.io.DataInputStream.readInt(DataInputStream.java:392) > at > org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63) > at > org.apache.zookeeper.server.quorum.QuorumPacket.deserialize(QuorumPacket.java:83) > at > org.apache.jute.BinaryInputArchive.readRecord(BinaryInputArchive.java:103) > at > org.apache.zookeeper.server.quorum.Learner.readPacket(Learner.java:153) > at > org.apache.zookeeper.server.quorum.Follower.followLeader(Follower.java:85) > at > org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:786) > 2016-01-19 13:12:49,698 - INFO > [QuorumPeer[myid=1]/0.0.0.0:2181:Follower@166] - shutdown called > java.lang.Exception: shutdown Follower > at > org.apache.zookeeper.server.quorum.Follower.shutdown(Follower.java:166) > at > org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:790) > This is immediately followed by 380 occurences of: > 2016-01-19 13:12:49,699 - INFO > [QuorumPeer[myid=1]/0.0.0.0:2181:NIOServerCnxn@1007] - Closed socket > connection for client /X.Y.Z.56:59028 which had sessionid 0x151b01ee8330234 > and a: > 2016-01-19 13:12:49,766 - INFO > [QuorumPeer[myid=1]/0.0.0.0:2181:FollowerZooKeeperServer@139] - Shutting down > 2016-01-19 13:12:49,766 - INFO > [QuorumPeer[myid=1]/0.0.0.0:2181:ZooKeeperServer@441] - shutting down > 2016-01-19 13:12:49,766 - INFO > [QuorumPeer[myid=1]/0.0.0.0:2181:FollowerRequestProcessor@105] - Shutting down > 2016-01-19 13:12:49,766 - INFO > [QuorumPeer[myid=1]/0.0.0.0:2181:CommitProcessor@181] - Shutting down > 2016-01-19 13:12:49,766 - INFO > [QuorumPeer[myid=1]/0.0.0.0:2181:FinalRequestProcessor@415] - shutdown of > request processor complete > 2016-01-19 13:12:49,767 - INFO > [QuorumPeer[myid=1]/0.0.0.0:2181:SyncRequestProcessor@209] - Shutting down > 2016-01-19 13:12:49,767 - INFO [CommitProcessor:1:CommitProcessor@150] - > CommitProcessor exited loop! > 2016-01-19 13:12:49,767 - INFO > [FollowerRequestProcessor:1:FollowerRequestProcessor@95] - > FollowerRequestProcessor exited loop! > 2016-01-19 13:13:09,418 - WARN [SyncThread:1:FileTxnLog@334] - fsync-ing the > write ahead log in SyncThread:1 took 30334ms which will adversely effect > operation latency. See the ZooKeeper troubleshooting guide > 2016-01-19 13:13:09,427 - WARN [SyncThread:1:SendAckRequestProcessor@64] - > Closing connection to leader, exception during packet send > java.net.SocketException: Socket closed > at > java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:121) > at java.net.SocketOutputStream.write(SocketOutputStream.java:159) > at > java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) > at > org.apache.zookeeper.server.quorum.Learner.writePacket(Learner.java:139) > at > org.apache.zookeeper.server.quorum.SendAckRequestProcessor.flush(SendAckRequestProcessor.java:62) > at > org.apache.zookeeper.server.SyncRequestProcessor.flush(SyncRequestProcessor.java:204) > at > org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:131) > 2016-01-19 13:13:09,428 - INFO [SyncThread:1:SyncRequestProcessor@187] - > SyncRequestProcessor exited! > As a small aside, the fsync log errors for the first two
ZooKeeper_branch35_openjdk7 - Build # 708 - Failure
See https://builds.apache.org/job/ZooKeeper_branch35_openjdk7/708/
###
## LAST 60 LINES OF THE CONSOLE
###
[...truncated 62.80 MB...]
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
[junit] at
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
[junit] at
org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
[junit] at
org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
[junit] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:622)
[junit] at java.lang.Thread.run(Thread.java:748)
[junit] 2017-10-10 10:07:23,378 [myid:] - INFO [New I/O boss
#18:ClientCnxnSocketNetty@208] - channel is told closing
[junit] 2017-10-10 10:07:23,378 [myid:127.0.0.1:13915] - INFO
[main-SendThread(127.0.0.1:13915):ClientCnxn$SendThread@1231] - channel for
sessionid 0x103f4b6dcdc is lost, closing socket connection and attempting
reconnect
[junit] 2017-10-10 10:07:23,511 [myid:127.0.0.1:14041] - INFO
[main-SendThread(127.0.0.1:14041):ClientCnxn$SendThread@1113] - Opening socket
connection to server 127.0.0.1/127.0.0.1:14041. Will not attempt to
authenticate using SASL (unknown error)
[junit] 2017-10-10 10:07:23,512 [myid:] - INFO [New I/O boss
#2772:ClientCnxnSocketNetty$1@127] - future isn't success, cause: {}
[junit] java.net.ConnectException: Connection refused:
127.0.0.1/127.0.0.1:14041
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
[junit] at
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
[junit] at
org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
[junit] at
org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
[junit] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:622)
[junit] at java.lang.Thread.run(Thread.java:748)
[junit] 2017-10-10 10:07:23,512 [myid:] - WARN [New I/O boss
#2772:ClientCnxnSocketNetty$ZKClientHandler@439] - Exception caught: [id:
0x2da174dc] EXCEPTION: java.net.ConnectException: Connection refused:
127.0.0.1/127.0.0.1:14041
[junit] java.net.ConnectException: Connection refused:
127.0.0.1/127.0.0.1:14041
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
[junit] at
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
[junit] at
org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
[junit] at
org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
[junit] at
org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
[junit] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:622)
[junit] at java.lang.Thread.run(Thread.java:748)
[junit] 2017-10-10 10:07:23,513 [myid:] - INFO [New I/O boss
#2772:ClientCnxnSocketNetty@208] - channel is told closing
[junit] 2017-10-10 10:07:23,513 [myid:127.0.0.1:14041] - INFO
[main-SendThread(127.0.0.1:14041):ClientCnxn$SendThread@1231] - channel for
sessionid
