Tim, You can duplicate this bug in just a few lines of python by doing an infinite update loop on a single doc. From my experience, revision number 29,107 is the magic number that causes seg faults.
I put it out on the erlang-questions list and Bjorn said that it was most likely because the erlang VM is using a recursive function internally that exceeds stack space. For reference, a copy of a failing db can be found at [1]. The docid that causes errors is "1". HTH, Paul Davis [1] http://www.davispj.com/rev_errors.couch On Fri, Feb 27, 2009 at 10:09 AM, Tim Somers <somers....@gmail.com> wrote: > Thanks, I will purge the db from time to time, that should keep me going for > the time being. > > As for the heart of the problem, I still have the offending db on my disk, > after compaction it is only 1.1Megs. Can this be of any help locating the > problem? > > Thanks for the great support, and for the great project that couchdb is. > Tim > > > On Fri, Feb 27, 2009 at 3:22 PM, Damien Katz <dam...@apache.org> wrote: > >> If you purge the doc it will discard the revision history. See the test >> suite for the purge test to see how to use it. >> >> Purge has caveats. Purge doesn't work with replication at all, the purge >> isn't replicated, the doc is simply "forgotten". You cannot purge anything >> during a compaction. If you do 2 purges in a row (before the views have a >> chance to refresh), all the db's view indexes must be rebuilt from scratch >> (In your case, with 51 docs, this doesn't really matter). >> >> -Damien >> >> >> >> On Feb 27, 2009, at 9:07 AM, Tim Somers wrote: >> >> Thanks for the answer, I hope the work you mentioned can solve some >>> things. >>> In the mean while, can my problem be solved if from time to time I delete >>> the document and recreate another with the same id and contents? I'm not >>> using any replication (yet) by the way. >>> >>> Tim >>> >>> >>> On Fri, Feb 27, 2009 at 2:56 PM, Damien Katz <dam...@apache.org> wrote: >>> >>> It's probably the "lots of updates" that's causing the problem. CouchDB >>>> tracks a revision history of each doc, indefinitely. If the list gets >>>> longer >>>> than can be held in memory, you get errors. (that it is a seg fault >>>> rather >>>> than an recoverable error is a bug in the erlang vm, IMO). >>>> >>>> There is revision stemming work that's on the way, that addresses this >>>> exact problem (though with caveats for replication). >>>> >>>> -Damien >>>> >>>> >>>> >>>> >>>> On Feb 27, 2009, at 3:36 AM, Tim Somers wrote: >>>> >>>> Hi all, >>>> >>>>> >>>>> I've been using couchdb in combination with py-simplecouchdb since a >>>>> couple >>>>> of weeks now on a small dataset (only 51 docs) with lots of updates. >>>>> Yesterday I checked out the latest update from svn, and left my >>>>> application >>>>> running all night. This morning, the couchdb process had closed. >>>>> After restarting it, everything seems to be running fine for read >>>>> access, >>>>> but on an update of any document, I get this error: >>>>> [debug] [<0.64.0>] 'PUT' /heasys/alert_3505_nomessages {1,1} >>>>> Headers: [{'Accept',"application/json, text/javascript, */*"}, >>>>> {'Accept-Charset',"ISO-8859-1,utf-8;q=0.7,*;q=0.7"}, >>>>> {'Accept-Encoding',"gzip,deflate"}, >>>>> {'Accept-Language',"en-us,en;q=0.5"}, >>>>> {'Connection',"keep-alive"}, >>>>> {'Content-Length',"239"}, >>>>> {'Content-Type',"application/json; charset=UTF-8"}, >>>>> {'Host',"localhost:5985"}, >>>>> {'Keep-Alive',"300"}, >>>>> {'Referer'," >>>>> http://localhost:5985/_utils/document.html?heasys/alert_3505_nomessages >>>>> "}, >>>>> {'User-Agent',"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6) >>>>> Gecko/2009020409 Iceweasel/3.0.6 (Debian-3.0.6-1)"}, >>>>> {"X-Requested-With","XMLHttpRequest"}] >>>>> Segmentation fault >>>>> No difference in the error except for the headers whether I test it with >>>>> my >>>>> application or the futon interface. >>>>> >>>>> Any ideas, anyone? >>>>> >>>>> Thanks >>>>> Tim Somers >>>>> >>>>> >>>> >>>> >> >
