Thanks, Paul. I don't see the replicator_db one in JIRA, so I'll file it. I can get the stats one to reproduce consistently in my environment, so if I can be of any help to Adam or others in continuing to test this, let me know.
Best, -Jake On Fri, May 20, 2011 at 1:54 PM, Paul Davis <paul.joseph.da...@gmail.com> wrote: > On Fri, May 20, 2011 at 1:40 PM, Jake Levirne <couc...@jakelevirne.com> wrote: >> Hi All- >> >> I had posted a note a little while back about futon tests failing for >> me, but I was running against trunk. I'm now running against a dev >> build of the 1.1.x branch (make dev; utils/run) and still getting >> futon test suite errors (below). All my etap tests pass. >> >> I'm new to the couchb community and looking for guidance on whether I >> should file an issue for these or not. >> >> replicator_db failure 164016ms >> >> 1. Run with debuggerAssertion failed: typeof >> repDoc2._replication_state === "undefined" >> 2. Assertion failed: typeof repDoc2._replication_state_time === "undefined" >> > > I don't think I've seen this error and I'm not super familiar with > this part of the code. Feel free to create an issue for it if one > doesn't already exist. > >> stats failure 49365ms >> >> 1. Run with debuggerAssertion 'triggered, "We managed to force a >> all_dbs_active error."' failed: We managed to force a all_dbs_active >> error. >> > > This one I do know about. I'm pretty sure the test has a big > race-condition that occasionally fails depending on the phase of the > moon and current tide levels. This also touches on some of deeper > parts of the internals dealing with the db ref counter business and > all that jazz so fixing it so that its less racy could be a fairly > involved issue. I do know that Adam has some work somewhere that > removes the ref counting and replaces it with monitors and refs to the > same effect. If someone wants to get that cleaned off and ready for > trunk that'd be cool. Though I dunno if such a major change would make > it back into 1.1. > >> >> I also get a failure on view_sandboxing complaining about the >> installed SpiderMonkey version: >> >> view_sandboxing failure 8145ms >> >> 1. Run with debuggerAssertion 'Warning: installed SpiderMonkey >> version doesn't allow sealing of arrays' failed: expected '2', got '3' >> >> But I installed from 1.8.0-rc1 source using these instructions: >> http://wiki.apache.org/couchdb/Installing_SpiderMonkey >> > > This is innocuous. Its just saying that we can't seal things in the > view engine. I'm 95% certain that this was fixed after that 1.8.0rc1 > tarball was released as well. Most of the devs use the version of > Spidermonkey that Homebrew installs. Recently Mozilla released a 1.8.5 > tarball that (once we update support for it) should silence this > warning. There's a patch in JIRA to support 1.8.5 but it comes at the > cost of discarding support for 1.7 which we were wanting to avoid. At > some point I plan on making a version of couchjs written directly for > 1.8.5 that we'll compile instead of the current one when we detect > 1.8.5 support. > >> I'm on Ubuntu 10.04.2 64-bit server. Browser is FF3.6.17 running on >> Win7. Here's my couch log file: >> http://dl.dropbox.com/u/9276140/couch.log (it shows several server >> terminations). The run that produced the above errors starts at [Fri, >> 20 May 2011 15:38:23 GMT]. Also, here's my local_dev.ini: >> http://dl.dropbox.com/u/9276140/local_dev.ini (though the only change >> I made to it was to set the bind_address to 0.0.0.0). > > The other terminations you refer to are most likely just log noise. > Erlang scares a lot of the uninitiated with the amount of tracebacks > from processes dying and other log noise that it produces but this is > just a side effect of the "let it crash" philosophy that's baked into > the language. Another project that might be fun would be to write two > log files like normal web servers. >
