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 >> >> >> >> >> >>
