What causes general exception: std::bad_alloc when performing a shielded transaction
Hello out there in Internet land,
A number of people have reported a that they are experiencing a
general exception: std::bad_alloc error.
std::bad_alloc is the type of the object thrown as exceptions by the allocation functions to report failure to allocate storage.
The allocates requested number of bytes. These allocation functions are called by new-expressions to allocate memory in which new object would then be initialized. They may also be called using regular function call syntax.
- Called by non-array new-expressions to allocate storage required for a single object. The standard library implementation allocates count bytes from free store. In case of failure, the standard library implementation calls the function pointer returned by std::get_new_handler and repeats allocation attempts until new handler does not return or becomes a null pointer, at which time it throws std::bad_alloc. This function is required to return a pointer suitably aligned to hold an object of any fundamental alignment.
So the error is related to memory allocation, and by not having enough it throws this error.
Normally you can allocate more swap space on the VPS that will alleviate this issue, but some people have reported that this does not help.
I have found that at a bare minimum the zend daemon needs 2.88 GB of available memory or the daemon will crash if you try to do a shielded transaction. This requirement will be less once Sapling is implemented but at the current time this is what I have be able to get my nodes stable at.
It is recommended to have a minimum of 1 GB of RAM and 1.88 GB of swap. More RAM is better, but extra swap will still be ok.
Please note: Some VPS providers do limit swap space allocation which could be at play in scenarios where this error is being thrown and extra swap space has been provided.
Another issue at play is that the RAM may not be completely free. Hairetikos on the zencash slack has suggested the following:
- terminate zend and secnodetracker processes (as standard user).
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
- start zend and secnodetracker processes again (as standard user)
I am compiling a list of failures and successes for VPS providers, so if you use a VPS provider, please let me know of your VPS provider name, what RAM and swap configuration you have, and whether or not you have any issues or if everything is working fine. I am looking to see if there are any glaring anomalies with the gathered data.
So far people have reported slow challenge times on Vultr even with the recommended allocated RAM and swap size.
Please hit me up with any questions and a later blog post will be published with further information.