TLS Memory Leak on HTTPS Web Server and HTTPS Client (CYW943907AEVAL1F)

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ChMa_3922746
Level 5
Level 5
10 likes received 10 likes given 5 likes given

It appears that there is a bit of a memory leak on my HTTPS web server and HTTPS client.  The common link is TLS. 

After repeated serving of web pages to a given client (via the web server) or periodically connecting to an external server (via the client), printing malloc_info shows the arena/uordblks/keepcost counting in one direction (and that direction is "up").

I see various threads on TLS memory leaks on this forum, but none that are recent, helpful or conclusive.

I was wondering if anyone has observed this recently, and if so, were there any debugging techniques that were hepful?  Digging into the underbelly of TLS doesn't sound like a fun project...

Suggestions are welcome.  Thanks!

0 Likes
1 Solution

Update:  I upgrade to SDK6.4, and I see that the problem does not exist even with the crypto HW acceleration enabled.  This problem appears to no longer exist.

View solution in original post

0 Likes
6 Replies
lock attach
Attachments are accessible only for community members.
ChMa_3922746
Level 5
Level 5
10 likes received 10 likes given 5 likes given

Going back to basics:  I created a new Eclipse workspace with the default SDK.  I built snip.https_server right from the SDK but added a while loop that periodically prints the heap stats (see attachment). 

The default https_server exhibits the same heap expansion.  (The test scenario is an HTTPS client written in Java which fetches the home page ever few seconds.)  Every so often (few minutes, typically), the heap grows by 4kB.   After running for an hour, or so, I can see the memory being slowly consumed:

-------------------SYS DBG MEM HEAP DIAGNOSTIC-----------------------

malloc_info {

    arena:       163736;    /* total space allocated from system */

    ordblks:       430;    /* number of non-inuse chunks */

    smblks:          0;    /* unused -- always zero */

    hblks:           0;    /* number of mmapped regions */

    hblkhd:          0;    /* total space in mmapped regions */

    usmblks:         0;    /* unused -- always zero */

    fsmblks:         0;    /* unused -- always zero */

    uordblks:    125816;    /* total allocated space */

    fordblks:    37920;    /* total non-inuse space */

    keepcost:     8232;    /* top-most, releasable (via malloc_trim) space */

};

This is very bad news...

0 Likes

Here is a bit of surprise and might be of interest to the WICED dev team:  When I backed out the SDK to version 6.0, the heap "creep" stopped and has behaved over the last couple of days. 

I wonder if there was a TLS memory leak introduced since 6.0 (or perhaps something else)?

0 Likes

SDK6.0 is definitely more stable than 6.2.  Another bonus is that, on Linux Mint, the console prints normally (Square Characters Showing up in Console Window (Linux) ).  OTA2 is not as functional in SDK6.0, however.

list_3922746 wrote:

Here is a bit of surprise and might be of interest to the WICED dev team:  When I backed out the SDK to version 6.0, the heap "creep" stopped and has behaved over the last couple of days. 

I wonder if there was a TLS memory leak introduced since 6.0 (or perhaps something else)?

You are reporting a memory leak in latest sdk and it was working in sdk-6.0.

This is clearly a bug report.

I'm wondering why this is marked as "correct answer".

0 Likes

Going to the SDK6.0 appeared to fix the immediate problem, but you are right... it appears to be a bug.  I did raise this one as a follow-up: SDK6.2 Breaks TLS Compared to SDK6.0 (CYW943907AEVAL1F)

0 Likes

Update:  I upgrade to SDK6.4, and I see that the problem does not exist even with the crypto HW acceleration enabled.  This problem appears to no longer exist.

0 Likes