Quote from: trev on August 26, 2015, 03:42:05 AM

Quote from: goatpig on August 24, 2015, 09:55:55 PM

So you are saying it takes 24h+ to crash? Can you keep an eye on the process memory? I'll run some tests on my own.

I got a third crash at 20150825_2016. It looks like Armory has to have been running for 24++ hrs in order to
get to the condition that triggers the std::bad_alloc. The approximate 48 hr interval that I see is probably due to
the fixed times of day that I use the PC. I sent 1.5BTC from bitcoin-qt to Armory-watch. Armory popped up the
std::bad_alloc window a few seconds after bitcoin-qt said it had sent the TX. I think the problem occurs when
Armory receives the raw TX. After restarting, it gets the TX from the block without a problem (but that's not after
a 24++ hr delay).

The memory usage remained fairly constant for the 48 hrs, including after the exception.
Armory: VIRT = 1052M RES = 288M SHR = 19M
Bitcoin-qt VIRT = 1121M RES = 404M SHR = 12M

I'm not having any success debuging ArmoryQt.py with gdb. I'll just try to get a crash in less than 48 hrs.

What's the total size of your DB? The headers DB alone?

https://github.com/etotheipi/BitcoinArmory/blob/ffreeze/cppForSwig/mdb/mdb.c#L588

Reduce this value to 16MB and rebuild a new DB with that, see if it suffers from the bad_alloc.