-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an option for static or pool-based memory allocation #2
Comments
@igrr Is it possible to handle an allocation failure gracefully in axtls, at least as a workaround for now until static allocation is worked through? I'm hitting the same issue as everyone else with SSL and realloc, but, I was curious if we could handle a nullptr being given by realloc, instead of just calling panic. EDIT: So, I think I answered my own question - Yes, it absolutely can. "increase_bm_data_size" is the only function I've modified so far, which now returns an integer saying if it succeeded or not. If not, I just throw SSL_ERROR_CONN_LOST, WiFiClientSecure::connect reports -1 in its return, and then the code continues where it used to crash. I'm sure bigint and the other calls can make it explode too, but, I've never seen it crash there. I'm not entirely sure what was allocating RAM in the heap to cause the fragmentation, as I eliminated all possible sources (I believe, at least), and still saw the crash after 10-15 minutes - This was with ~31K of free heap. However, after the aforementioned workaround, I see it fail once or twice in the loop, and then returns to working. The only note, though, is that I could not get it working with umm_malloc. I always saw curious exceptions in umm_assimilate_up when SSLContext's destructor was called, and couldn't track them down. Reverting to the previous malloc code seems to have fixed it. |
@liquidfalcon thanks for the suggestion, i have implemented the workaround you described. |
May be you can integrate this project for better heap allocation? Here is an article about it https://blog.cesanta.com/embedded-heap-behaviour-analysis-and-improvement. |
ESP8266 Arduino core uses umm_malloc since last release. |
Cool! And is it working as expected: Less heap fragmentation, etc? |
Yes, it's much better now. Although some fragmentation is still inevitable, and requesting 16k TLS buffer fails occasionally. Umm_malloc is slightly slower, and even more so if heap poisoning is enabled. |
Necessary because heap fragmentation becomes an issue as seen here: esp8266/Arduino#1084
The text was updated successfully, but these errors were encountered: