Skip to content
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

Open
igrr opened this issue Nov 26, 2015 · 6 comments
Open

Add an option for static or pool-based memory allocation #2

igrr opened this issue Nov 26, 2015 · 6 comments

Comments

@igrr
Copy link
Owner

igrr commented Nov 26, 2015

Necessary because heap fragmentation becomes an issue as seen here: esp8266/Arduino#1084

@liquidfalcon
Copy link

@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.

igrr added a commit that referenced this issue Feb 26, 2016
@igrr
Copy link
Owner Author

igrr commented Feb 26, 2016

@liquidfalcon thanks for the suggestion, i have implemented the workaround you described.

@slaff
Copy link
Contributor

slaff commented Apr 13, 2016

heap fragmentation becomes an issue

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.

@igrr
Copy link
Owner Author

igrr commented Apr 13, 2016

ESP8266 Arduino core uses umm_malloc since last release.

@slaff
Copy link
Contributor

slaff commented Apr 13, 2016

ESP8266 Arduino core uses umm_malloc since last release.

Cool! And is it working as expected: Less heap fragmentation, etc?

@igrr
Copy link
Owner Author

igrr commented Apr 13, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants