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

Fix memory leak of ext_host_name in ssl_ext structure #49

Closed
wants to merge 3 commits into from
Closed

Fix memory leak of ext_host_name in ssl_ext structure #49

wants to merge 3 commits into from

Conversation

earlephilhower
Copy link
Contributor

@Jeroen88 found a memory leak in axtls where the new ext_host_name pointer was leaking on every SSL reconnection, eventually eating up all RAM and crashing the chip (see esp8266/Arduino#3428 ).

This patch just checks if we actually set a host name (strdup()d on the heap), and if so just frees it on the ssl_ext_free call. This should eliminate the leakage.

Constant text strings actually take up SRAM space on the ESP8266
because the .RODATA segment must be copied to RAM at startup since
FLASH isn't byte-accessible.

Move the constant format strings in a printf completely into FLASH
and add a wrapper to copy it into a local stack-allocated space
when needed, freeing up about 3100 bytes of RAM for use.  This doesn't
make FLASH usage any higher, either, since those strings were already
being stored there (but never used after the power-on startup code).

Minor edits required in some of the output/debug/tracing functions,
but no logic changed.
ssl_ext has a hostname which is strdup()'d (i.e. allocated) but wasn't
freed in the ssl_ext_free() routine.  This lead to the leaking of that
strdup()'d pointer on every SSL close/reopen cycle.

Patch simply checks if there's a string and frees it in the ssl_ext_free
routine.  Also adds a sanity check in set_ext_hostname() to not try and
free() the old string if there is not one present.
@earlephilhower
Copy link
Contributor Author

Oops, this one accidentally included the other commit I'd sent in.

I'll submit a new PR later tonight from a clean branch to avoid it pulling in bc27f4b . Looks like I'll need to destroy my existing repo and re-fork, but it shouldn't be a big deal.

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

Successfully merging this pull request may close these issues.

1 participant