couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Crash of CouchDB 1.2.x
Date Thu, 01 Mar 2012 15:52:20 GMT
Hi Stefan,

thanks for the report, this is very helpful!

Can you tell us how you installed 1.2.x? Is it a fresh installation,
did you do an in-place update from an earlier installation (earlier
1.2.x or 1.1.x or 1.0.x?

Without having dug too much yet and more as a pointer for the other
devs here, I remember seeing io_lib_* errors in cases where we catch
exceptions in an attempt to make prettier messages, but then the
catch-all clause tries to print whatever is actually unexpected
and fails there, resulting in the io_lib_* stacktrace when
attempting to print the actual stacktrace that subsequently
gets lost.


On Mar 1, 2012, at 12:17 , Stefan Kögl wrote:

> Hello,
> My experiments to replicate some live data / traffic to a CouchDB
> 1.2.x (running the current 1.2.x branch + the patch from [1]) that
> sparked the indexing speed discussions, did also yield another
> (potential) problem. First sorry for not further reporting back any
> performance measurements, but I didn't yet find the time to run the
> tests on my machines.
> Anyway, I found the following stack traces in my log (after noticing
> that some requests failed and compaction of a view stopped)
> The files starts at the first failed requests. Every request before
> that returned a positiv (ie 2xx) status code. The crash might have
> some "natural" reason (such as timeouts, lack of RAM, etc), but I'm
> not sure how to interpret Erlang stack traces. Can somebody point me
> in the right direction for diagnosing the problem?
> Thanks,
> -- Stefan
> [1]

View raw message