Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of robert.newson@gmail.com
 designates 209.85.214.52 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=ERDPRgIzqrvcWQVmOk/7maE886Ipxoq/0NG+g+38GgquHMMuS7JqUJnLa+cBXR1TmL
         KNi7nuQWcTnFA4ijZMY0sa39ywuydvIU7VE39G0dhNX5Qz2DC3TSdtxHVCzHLzxNaTJW
         +XEwpLe6zh9xmezyw37WWz1jTwrHIw/qwB2Ik=
MIME-Version: 1.0
In-Reply-To: <BANLkTimrtpXFvS-NT8bwYEA58sKR-9tbcg@mail.gmail.com>
References: <BANLkTi=Nuki4TLJQVEmC2ASms8TK53nzqA@mail.gmail.com>
	<A58F884F-3A71-42AC-A81F-42B6C436E288@apache.org>
	<BANLkTimrtpXFvS-NT8bwYEA58sKR-9tbcg@mail.gmail.com>
Date: Mon, 30 May 2011 11:21:39 +0100
Message-ID: <BANLkTimDWxTE6_Vk8U3+r3ycJ8JRAk6MOQ@mail.gmail.com>
Subject: Re: [VOTE] Apache CouchDB 1.1.0 release, round 2.
From: Robert Newson <robert.newson@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I should clarify: the failure on R14B03 is because of a change to OTP.

Specifically, when using "cancel":true to stop a running replication
task, we call supervisor:terminate_child and then
supervisor:delete_child. In both cases, we expect 'ok' as the result.
In R14B03, the delete_child call returns {error, not_found} instead.
This lines up with OTP-9167 where they alter the behavior of temporary
child processes. Since these cannot be restarted, they are
automatically deleted once restarted.

I have already applied and tested a fix for this that will be
compatible with all versions.

B.

On 30 May 2011 11:14, Robert Newson <robert.newson@gmail.com> wrote:
> I'm aborting round 2 because of;
>
> 1) replication.js failure on R14B03
> 2) Failure of candidate to build on Windows due to old version of
> autoconf/automake
>
> I have fixes for both issues and will release a round 3 candidate soon.
>
> Additional testing, particularly outside of our test suites, is still use=
ful.
>
> B.
>
> On 28 May 2011 19:32, Noah Slater <nslater@apache.org> wrote:
>> Make check ok.
>>
>> Results from unit tests in Firefox:
>>
>> * First base on "basics" caused segfault in CouchDB. Started over with G=
DB.
>>
>> * Second time through with "cookie_auth" failed with "file exists" messa=
ge.
>>
>> * Second time through "design_docs" caused segfault:
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_INVALID_ADDRESS at address: 0x00000000107c3bc0
>> 0x00000000107c3bc0 in ?? ()
>> (gdb) backtrace
>> #0 =A00x00000000107c3bc0 in ?? ()
>> Cannot access memory at address 0x107c3bc0
>> #1 =A00x00007fff8779b5b1 in EVP_DigestInit_ex ()
>> #2 =A00x00007fff8776989d in ssleay_rand_bytes ()
>> #3 =A00x00007fff87768f2e in ssleay_rand_pseudo_bytes ()
>> #4 =A00x000000001074307a in rand_bytes_1 ()
>> #5 =A00x00000000100fdc07 in process_main ()
>> #6 =A00x000000001006ff5e in sched_thread_func ()
>> #7 =A00x000000001018e8db in thr_wrapper ()
>> #8 =A00x00007fff833694f6 in _pthread_start ()
>> #9 =A00x00007fff833693a9 in thread_start ()
>>
>> * Restarted test suite and got a segfault in "basics" again:
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_INVALID_ADDRESS at address: 0x00000000107c3bc0
>> [Switching to process 95309 thread 0x2803]
>> 0x00000000107c3bc0 in ?? ()
>> (gdb) backtrace
>> #0 =A00x00000000107c3bc0 in ?? ()
>> Cannot access memory at address 0x107c3bc0
>> #1 =A00x00007fff8779b5b1 in EVP_DigestInit_ex ()
>> #2 =A00x00007fff8776989d in ssleay_rand_bytes ()
>> #3 =A00x00007fff87768f2e in ssleay_rand_pseudo_bytes ()
>> #4 =A00x000000001074307a in rand_bytes_1 ()
>> #5 =A00x00000000100fdc07 in process_main ()
>> #6 =A00x000000001006ff5e in sched_thread_func ()
>> #7 =A00x000000001018e8db in thr_wrapper ()
>> #8 =A00x00007fff833694f6 in _pthread_start ()
>> #9 =A00x00007fff833693a9 in thread_start ()
>>
>> At least it seems to be the same bit of code that is segfaulting.
>>
>> I am -1 on the release until we can figure out what's going on here.
>>
>> Perhaps I have a dodgy SSL library?
>>
>> I'm not sure how I could check for this, so looking for help!
>>
>>
>