From dev-return-20332-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Wed Jan 25 18:33:11 2012 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4EF469FF7 for ; Wed, 25 Jan 2012 18:33:11 +0000 (UTC) Received: (qmail 14583 invoked by uid 500); 25 Jan 2012 18:33:10 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 14553 invoked by uid 500); 25 Jan 2012 18:33:09 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 14545 invoked by uid 99); 25 Jan 2012 18:33:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Jan 2012 18:33:09 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Jan 2012 18:33:08 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 3B5A5162BD4 for ; Wed, 25 Jan 2012 18:32:48 +0000 (UTC) Date: Wed, 25 Jan 2012 18:32:48 +0000 (UTC) From: "Paul Joseph Davis (Commented) (JIRA)" To: dev@couchdb.apache.org Message-ID: <112472742.77250.1327516368244.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <2010305621.76140.1327485280224.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (COUCHDB-1393) badmatch on big binary MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/COUCHDB-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193181#comment-13193181 ] Paul Joseph Davis commented on COUCHDB-1393: -------------------------------------------- I'd be quite interested to know what sort of fsync options were being used on the database/server in question where this occurred. > 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 > 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, <>} = 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