- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was doing a bit of malloc debug since I saw memory increasing whenever new clients (Firefox web browser) connected to the WICED HTTPS server (TLS enabled). I observed that the function http_server_deferred_connect_callback() allocates memory for each new client, but never frees the memory. Over time the memory usage creeps up and up.
The function call that allocates the memory is context = malloc_named("https", sizeof(wiced_tls_context_t));
Can anyone think of a way to free up the memory after a period of time has expired (i.e., the client has not connected for some period of time)? (Other than stopping and re-starting the server, that is.)
Thanks!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ZhengbaoZ_96 wrote:
Would you please try "free( http_server ); " ?
Don't do that unless you use malloc to allocate memory for http_server.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Would you please try "free( http_server ); " ?
#ifdef USE_HTTPS
wiced_https_server_stop(http_server);
#else
wiced_http_server_stop(http_server);
#endif
free( http_server );
wiced_rtos_deinit_semaphore(&aws_config_semaphore);
/* Cleanup DNS server */
wiced_dns_redirector_stop(&dns_redirector);
/* Turn off AP */
wiced_network_down( WICED_CONFIG_INTERFACE );
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you. I tried it and found that free("http_server") crashes the processor. On further investigation, I think that perhaps tls_context's build-up but some are never free'd. After a while, and a few different clients connecting, I see multiple allocations which persist:
tls_init_context 228
180
180
180
180
180
308
56
308
224
56
308
224
84
84
84
839
Stopping the server & re-starting is not an option in my case. I would expect the main server loop in "wiced_http_server_stop()" to clean up the hanging contexts, but maybe not...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hello :
We have tls_host_free function that is used for TLS context fress , would you please take a look at it if it can match your requests?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ZhengbaoZ_96 wrote:
Would you please try "free( http_server ); " ?
Don't do that unless you use malloc to allocate memory for http_server.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Right. "free( http_server );" crashes the device.
In the file http_server.c, the function http_server_deferred_connect_callback() contains the lines:
if ( socket->tls_context == NULL )
{
context = malloc_named("https", sizeof(wiced_tls_context_t));
if (context == NULL)
{
HTTP_DEBUG((" L%d : %s() : Failed to allocate TLS context\r\n", __LINE__, __FUNCTION__));
return WICED_OUT_OF_HEAP_SPACE;
}
socket->context_malloced = WICED_TRUE;
Is there a way to search the sockets in an HTTPS server and then free the allocations? Perhaps the sockets need to be removed first?
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I stumbled across the function "wiced_http_disconnect_all_response_stream(server);" which appears to close the streams and free up the memory. So, I think I have my answer.
This still leaves the observation that the server does not, by default, close streams that haven't been used for a while (or orphaned?). Hence, memory allocation keeps building and building over time.