Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Wed, 25 Jan 2012 09:54:40 +0000 (UTC)
From: "Jan Lehnardt (Created) (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: 
 <2010305621.76140.1327485280224.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Created] (COUCHDB-1393) badmatch on big binary
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

badmatch on big binary
----------------------

                 Key: COUCHDB-1393
                 URL: https://issues.apache.org/jira/browse/COUCHDB-1393
             Project: CouchDB
          Issue Type: Bug
            Reporter: Jan Lehnardt


via dev@ by Peta Bogdan <bog495@gmail.com>


Hello,

I have a small database around 120 MB with approximately 16,000 documents.

However, it happens (also from futon) that I get this error:

[Tue, 17 Jan 2012 07:22:01 GMT] [error] [<0.185.0>] {error_report,<0.30.0>,
                    {<0.185.0>,crash_report,
                     [[{initial_call,{couch_file,init,['Argument__1']}},
                       {pid,<0.185.0>},
                       {registered_name,[]},
                       {error_info,
                        {exit,
                         {{badmatch,
                           {ok,
                            9_MEGABYTES_BINARY}},
                          [{couch_file,read_raw_iolist_int,3},
                           {couch_file,maybe_read_more_iolist,4},
                           {couch_file,handle_call,3},
                           {gen_server,handle_msg,5},
                           {proc_lib,init_p_do_apply,3}]},
                         [{gen_server,terminate,6},
                          {proc_lib,init_p_do_apply,3}]}},
                       {ancestors,[<0.184.0>]},
                       {messages,
                        [{'$gen_call',
                          {<0.10840.18>,#Ref<0.0.3.20907>},
                          bytes}]},
                       {links,[<0.190.0>]},
                       {dictionary,[]},
                       {trap_exit,true},
                       {status,running},
                       {heap_size,1597},
                       {stack_size,24},
                       {reductions,65666}],
                      [{neighbour,
                        [{pid,<0.190.0>},
                         {registered_name,[]},
                         {initial_call,
                          {couch_ref_counter,init,['Argument__1']}},
                         {current_function,{gen_server,loop,6}},
                         {ancestors,[<0.188.0>,<0.187.0>,<0.184.0>]},
                         {messages,[]},
                         {links,[<0.185.0>]},
                         {dictionary,[]},
                         {trap_exit,false},
                         {status,waiting},
                         {heap_size,610},
                         {stack_size,9},
                         {reductions,362}]}]]}}

If this error occurs to frequently causes couch_server to reach its max
restart frequency causing the entire supervision tree to shutdown and hence
the database server instance disappears.

The function couch_file:read_raw_iolist_int/3 calls file:pread which
returns {ok, Binary}. This Binary has almost 9 megabytes in size, which is
very strange.
I think this does mean that the function file:pread/3 is instructed to read
from wrong position.

The only reason I can think of is that the value of 'TotalBytes' from line
(1) doesn't match the value of 'TotalBytes' from line (2)

(1) TotalBytes = calculate_total_read_len(BlockOffset, Len),
(2) {ok, <<RawBin:TotalBytes/binary>>} = file:pread(Fd, Pos, TotalBytes),

The possible answer would be that in certain conditions the function
calculate_total_read_len/2 doesn't return the expected value.

Server: CouchDB/1.1.1 (Erlang OTP/R14B04)
OS: OpenBSD 5.0 GENERIC.MP#63 amd64

Now, the trouble is how to circumvent this situation.

Thank you in advance,

Bogdan

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira