couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Futon replicator_db and stats tests failing for me on 1.1.x
Date Fri, 20 May 2011 17:54:33 GMT
On Fri, May 20, 2011 at 1:40 PM, Jake Levirne <couchdb@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.

Mime
View raw message