If there are any proposed patches to replicator_db timing I'd be happy to try them out, as I haven't yet managed to get this test to work at all in Win7 or Win8 with the latest build. The failures are not always identical: the number of "copy === null" failures varies, and I've occasionally had two "foo666" failures rather than one. But the overall result is always the same, so I may happen to have a good testbed.
Nick On 25 February 2012 19:12, Dave Cottlehuber <[email protected]> wrote: > On 25 February 2012 12:39, Jeroen Janssen <[email protected]> > wrote: > > Hi, > > > > Here are my results so far. > > > > setup-couchdb-1.2.0_otp_R15B.exe > > Windows 7 x64 > > Google Chrome 19.0.1049.3.dev-m > > signature OK > > md5 & sha OK > > No malware - Avira Internet Security 2012 > > > > Test failures: > > attachment_ranges > > 1.Assertion failed: expected '"bytes 0-28/29"', got '"bytes 0-29/29"' > > 2.Assertion failed: expected '"29"', got '"30"' > > Thanks Jeroen, > > above are bad chrome, so that's fine for me. > > > replicator_db > > 1.Assertion failed: expected 'null', got > > > '{"_id":"foo666","_rev":"1-8f008c4354eb07d5fbfc399a84bc88a1","value":666}' > > > > (I believe both of these failures are known/accepted already) > > I also had this previously on round 1 of 1.2.0 voting, and after > fiddling with the timing in the test suite, it disappeared. However I > couldn't get it to repeat in 1.2.0 round 2 (this build). I'm don't see > this is a blocker but until I can at least trigger it reliably I can't > do a patch to fix it. If you can get it reliably, try hacking in > > https://github.com/apache/couchdb/blob/1.2.x/share/www/script/test/replicator_db.js > > > However, in my couchdb.log I see a total of 28 crash_reports happening > > during the test. I don't know if this is 'expected' to happen during > > the test. > > I put the full couchdb logging of running the whole test suite at > > http://db.tt/mcmruUSZ > > As Jason pointed out, this is normal. > > CouchDB is built up of a number of erlang/OTP applications. In the OTP > world these could be independently packaged and distributed, although > Couch is a little way to go before that's possible. The way we set up > logging also puts these application startups/shutdowns in the log, > notably every time we restart couchdb, we simply call init:restart() > which hard stops the erlang VM and restarts it. This is easy for us > but messy in the logs. > > > If someone can confirm that all the crash_reports are expected, then I > > can +1 this. > > I'm happy with that - awesome! And thanks for testing trunk snapshots > over the last 6 or so months it was a great help. > > A+ > Dave >
