I've just gone through the C library code checkins made in last two months (from April).
Following are some of the related issues, probably this may give hints. Issue Date -------------- ---------- ZOOKEEPER-1887 April - 16 ZOOKEEPER-1695 April - 30 ZOOKEEPER-1836 May - 16 ZOOKEEPER-1938 June - 25 -Rakesh -----Original Message----- From: Patrick Hunt [mailto:ph...@apache.org] Sent: 01 July 2014 12:00 To: DevZooKeeper Subject: Re: ZooKeeper 3.5.0-alpha planning fyi I see it as far back as may 28 (and could have been failing before but we don't have history much before that): https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk/2316/console definitely some changes in there around may 20/21, but no smoking gun... https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk/changes Perhaps run with valgrind or something like that? We've run it before to good effect... Patrick On Mon, Jun 30, 2014 at 11:22 PM, Raúl Gutiérrez Segalés <r...@itevenworks.net> wrote: > On 30 June 2014 22:41, Patrick Hunt <ph...@apache.org> wrote: > >> I'm seeing quite a few segfault type failures in the c client on >> jenkins. That used to be pretty uncommon. Not sure when it started. >> >> Here's another example >> >> *** glibc detected *** ./zktest-mt: free(): invalid pointer: >> 0x00002b0a75afd000 *** >> >> >> https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk >> /2346/console >> > > So the last big chunk of code that landed in the C client was the > removeWatches impl (which still needs an update to adhere to the last > changes in the Java impl). Although, its test does pass: > > Zookeeper_simpleSystem::testRemoveWatchers ZooKeeper server started : > elapsed 4634 : OK > > but the error is suspiciously near by.. I'll take a look. > > > -rgs > > > > >> >> Patrick >> >> On Mon, Jun 30, 2014 at 10:32 PM, Raúl Gutiérrez Segalés >> <r...@itevenworks.net> wrote: >> > On 30 June 2014 22:26, Patrick Hunt <ph...@apache.org> wrote: >> > >> >> Also, does anyone have an idea where we stand with the c client >> >> and windows support? I see the build job is passing on trunk. Are >> >> folks able to successfully use that client? >> >> >> >> I see the c client on linux failing in some new ways, recent change? >> >> >> >> [exec] Zookeeper_operations::testConcurrentOperations1 : >> >> assertion : elapsed 24 >> >> [exec] /bin/bash: line 5: 11205 Segmentation fault >> >> >> >> >> ZKROOT=/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/src/c/../.. >> >> CLASSPATH=$CLASSPATH:$CLOVER_HOME/lib/clover.jar ${dir}$tst >> >> [exec] Zookeeper_multi::testCreateFAIL: zktest-mt >> >> >> > >> > I wonder if related to: >> https://issues.apache.org/jira/browse/ZOOKEEPER-1933 >> > >> > >> > -rgs >> > >> > >> > >> >> >> >> Patrick >> >> >> >> On Mon, Jun 30, 2014 at 9:53 PM, Patrick Hunt <ph...@apache.org> wrote: >> >> > Hi Flavio, do you think those jiras can get reviewed/finalized >> >> > before the end of the week? I'd like to try cutting an RC soonish... >> >> > >> >> > Patrick >> >> > >> >> > On Sun, Jun 29, 2014 at 5:02 AM, Flavio Junqueira >> >> > <fpjunque...@yahoo.com.invalid> wrote: >> >> >> +1 for the plan of releasing alpha versions. >> >> >> >> >> >> I'd like to have ZK-1818 (ZK-1810) and ZK-1863 in. They are >> >> >> both >> patch >> >> available. ZK-1870 is in trunk, but it is still open because we >> >> need a >> 3.4 >> >> patch. >> >> >> >> >> >> -Flavio >> >> >> >> >> >> >> >> >> On 26 Jun 2014, at 01:07, Patrick Hunt <ph...@apache.org> wrote: >> >> >> >> >> >>> Hey folks, we've been talking about it for a while, a few >> >> >>> people >> have >> >> >>> mentioned on the list as well as contacted me personally that >> >> >>> they would like to see some progress on the first 3.5 release. >> >> >>> Every release is a compromise, if we wait for perfection we'll >> >> >>> never get anything out the door. 3.5 has tons of great new >> >> >>> features, lots of hard work, let's get it out in a release so >> >> >>> that folks can use it, test it, and give feedback. >> >> >>> >> >> >>> Jenkins jobs have been pretty stable except for the known >> >> >>> flakey >> test >> >> >>> ZOOKEEPER-1870 which Flavio committed today to trunk. Note >> >> >>> that jenkins has also been verifying the code on jdk7 and jdk8. >> >> >>> >> >> >>> Here's my thinking again on how we should plan our releases: >> >> >>> >> >> >>> I don't think we'll be able to do a 3.5.x-stable for some time. >> What I >> >> >>> think we should do instead is similar to what we did for 3.4. >> >> >>> (this >> is >> >> >>> also similar to what Hadoop did during their Hadoop 2 release >> >> >>> cycle) Start with a series of alpha releases, something people >> >> >>> can run and test with, once we address all the blockers and >> >> >>> feel comfortable >> with >> >> >>> the apis & remaining jiras we then switch to beta. Once we get >> >> >>> some good feedback we remove the alpha/beta moniker and look >> >> >>> at making it "stable'. At some later point it will become the >> >> >>> "current/stable" >> >> >>> release, taking over from 3.4.x. >> >> >>> >> >> >>> e.g. >> >> >>> 3.5.0-alpha (8 blockers) >> >> >>> 3.5.1-alpha (3 blockers) >> >> >>> 3.5.2-alpha (0 blockers) >> >> >>> 3.5.3-beta (apis locked) >> >> >>> 3.5.4-beta >> >> >>> 3.5.5-beta >> >> >>> 3.5.6 (no longer considered alpha/beta but also not "stable" >> >> >>> vs >> 3.4.x, >> >> >>> maybe use it for production but we still expect things to >> >> >>> shake out) >> >> >>> 3.5.7 >> >> >>> .... >> >> >>> 3.5.x - ready to replace 3.4 releases for production use, >> >> >>> stable, >> >> etc... >> >> >>> >> >> >>> There are 8 blockers currently, are any of these something >> >> >>> that >> should >> >> >>> hold up 3.5.0-alpha? >> >> >>> >> >> >>> I'll hold open the discussion for a couple days. If folks find >> >> >>> this >> a >> >> >>> reasonable plan I'll start the ball rolling to cut an RC. >> >> >>> >> >> >>> Patrick >> >> >> >> >> >>
