tcatm reports:
*** glibc detected *** ./bitcoind: corrupted double-linked list: 0x0a78b468 ***
... possibly in listaccounts.
tcatm reports:
*** glibc detected *** ./bitcoind: corrupted double-linked list: 0x0a78b468 ***
... possibly in listaccounts.
possibly in other RPC methods, too. It died with getaccountaddress in debug.log, but didn't get glibc message as the terminal was closed.
Version: 009d5fb41f3aa39baeeb3f72454cdc14459fc67e (Merge branch 'listaddresses' into integration) with CORS patch (shouldn't cause it, though)
bitcoind: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
I just noticed the following (line numbers might not match, I discovered this while re-ordering some code):
In getaccountaddress() rpc.cpp:361: warning: control reaches end of non-void function
edit: ArtForz and lfm on IRC said, that code should never return inside a CRITICAL_BLOCK()
Returning from a CRITICAL_BLOCK is OK. CRITICAL_BLOCK uses local C++ objects to do the locking, which are guaranteed to be properly destructed no matter how the block is exited.
More data: there have been a couple more reports of bitcoind crashing under heavy RPC load, although nobody has been able to reproduce.
how do we know this isn't a hardware problem? does bitcoin check the consistency of its files and repair them automatically?
gavinandresen, were those reports from different people, or from one person? If they were from different people I'd push hardware problems further down the list of suspects. I wouldn't rule out hardware problems, of course.
jhyslop: bitcoind crashing/hanging reports were from other people (slush was one, I believe).
I still haven't seen it, running 3 or 4 instances of bitcoind on 2 or 3 different machines (Mac and Debian Linux).
No further reports of this, I'm going to close.