[ https://issues.apache.org/jira/browse/COUCHDB-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193142#comment-13193142 ]
Adam Kocoloski commented on COUCHDB-1393: ----------------------------------------- I've seen this happen before. file:pread/3 will return fewer bytes than requested if it starts at a valid position and reaches eof. The {ok, <<RawBin:TotalBytes/binary>>} pattern fails to match because the size is less than TotalBytes and CouchDB ends up stupidly trying to log the binary it receives instead. Robert Newson wrote a patch for us a while ago to sensibly log the fact that a mismatch occurred and suppress the multi-megabyte log entry. I'll try to dig it up and see if it applies. A 9MB pread request is very unusual and does point to an incorrectly computed value of TotalBytes. > 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 <bog...@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