couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <robert.new...@gmail.com>
Subject Re: [VOTE] Apache CouchDB 1.1.0 release, round 2.
Date Mon, 30 May 2011 10:21:39 GMT
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 useful.
>
> 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 GDB.
>>
>> * Second time through with "cookie_auth" failed with "file exists" message.
>>
>> * 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  0x00000000107c3bc0 in ?? ()
>> Cannot access memory at address 0x107c3bc0
>> #1  0x00007fff8779b5b1 in EVP_DigestInit_ex ()
>> #2  0x00007fff8776989d in ssleay_rand_bytes ()
>> #3  0x00007fff87768f2e in ssleay_rand_pseudo_bytes ()
>> #4  0x000000001074307a in rand_bytes_1 ()
>> #5  0x00000000100fdc07 in process_main ()
>> #6  0x000000001006ff5e in sched_thread_func ()
>> #7  0x000000001018e8db in thr_wrapper ()
>> #8  0x00007fff833694f6 in _pthread_start ()
>> #9  0x00007fff833693a9 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  0x00000000107c3bc0 in ?? ()
>> Cannot access memory at address 0x107c3bc0
>> #1  0x00007fff8779b5b1 in EVP_DigestInit_ex ()
>> #2  0x00007fff8776989d in ssleay_rand_bytes ()
>> #3  0x00007fff87768f2e in ssleay_rand_pseudo_bytes ()
>> #4  0x000000001074307a in rand_bytes_1 ()
>> #5  0x00000000100fdc07 in process_main ()
>> #6  0x000000001006ff5e in sched_thread_func ()
>> #7  0x000000001018e8db in thr_wrapper ()
>> #8  0x00007fff833694f6 in _pthread_start ()
>> #9  0x00007fff833693a9 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!
>>
>>
>

Mime
View raw message