On Fri, Feb 27, 2009 at 10:31 AM, Paul Davis <[email protected]> wrote: > 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.
Is there a JIRA issue for this problem? Regards, Jeff Hinrichs > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>>> >>>>>> >>>>> >>>>> >>> >>
