couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jake Levirne <>
Subject Re: Futon replicator_db and stats tests failing for me on 1.1.x
Date Fri, 20 May 2011 18:28:55 GMT
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.


On Fri, May 20, 2011 at 1:54 PM, Paul Davis <> wrote:
> On Fri, May 20, 2011 at 1:40 PM, Jake Levirne <> 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:
> 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:
>> (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:
>> (though the only change
>> I made to it was to set the bind_address to
> 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.

View raw message