Fix hash_test() memory leak in wolfcrypt/test/test.c #8506
Conversation
|
Jenkins retest this please |
|
Jenkins retest this please. to retry external tests |
|
Retest this please: "ERROR: Cannot delete workspace :Unable to delete" |
dgarske
left a comment
dgarske
left a comment
There was a problem hiding this comment.
Are all the changes in this PR needed?
Yes, I believe so. They are all good tests, even if unlikely to be encountered. The eyebrow raising code is surrounding the hash algos that are not implemented. For instance, it is unlikely (but not impossible) that someone might try to call If you agree with the logic and scope, there's one more check that is needed that I overlooked: what if the first item in |
I plan an update for only compiled-in algorithms and only reference the respective For future reference: the original code in question was introduced in 2016. Specifically commit It is this "
btw - I've now run thousands of iterations of the |
|
Hi @dgarske - I've updated the hash_test() in test.c and left as a separate commit for your review. Tested in a loop on an ESP32 monitoring heap and: make distclean
./configure --enable-crypttests
make -j$(nproc) wolfcrypt/test/testwolfcrypt
./wolfcrypt/test/testwolfcrypt |
|
FYI: PRB Test is failing with: |
…ix-hash-test-memory-leak
|
Retest this please: "PRB-single-flag.txt_110" "Found unhandled org.jenkinsci.plugins.workflow.support.steps.AgentOfflineException exception:" |
|
@dgarske now that this is approved, I can squash the commits. |
4 participants
Description
This PR fixes a memory leak in the
hash_testfunction ofwolfcrypt/test/test.cand adds some Espressif-specific heap checking features.Background
The memory leak was first brought to my attention by the Devin automated #8471.
I've reviewed the Espressif code. I was unable to find a memory leak.
I also had ChatGPT review the code. There were some false positives, but after I explained the multi-threaded nature of the library, ChatGPT was also unable to find any memory leak candidates.
From what I can see, there is no memory leak detected in any of the core wolfcrypt hash functions, only the test code around current line 6082 (no line as the file is too big to view online):
The problem is manifested when
#define WOLFSSL_SMALL_STACKis found in theuser_settings.h.Generally the test has been used as a "run once and exit" app, so it is unlikely anyone noticed there was a memory leak.
In my case, I typically run the tests in a loop for hours and days on embedded devices. See the #define TEST_LOOP setting.
After about 1,500+ loops, the ESP32 devices would run out of memory. I incorrectly assumed the problem was Espressif-specific.
I've run the benchmark in loops on 9 different devices for days now. Between ~5,000 and ~8,000 loops have completed successfully:
I've started a similar loop of the wolfcrypt test again with changes in this PR.
Changes
There's a new
DEBUG_WOLFSSL_ESP32_HEAPnow documented inesp32-crypt.h.The
PRINT_HEAP_CHECKPOINT(b, i)has been modified to accept two parameters: a breadcrumb string (b) and an integer index (i).The existing implementation of
PRINT_HEAP_CHECKPOINTwas not otherwise changed. A newPRINT_HEAP_CHECKPOINTwas added for the Espressif ESP-IDF environment.There's a new
PRINT_HEAP_ADDRESSthat prints the address of a newly allocated memory segment. In this PR, the address of the hash object.There's a new "placeholder" hash type created for known-but-not-implemented hash types. Previously the hash
freewould quietly fail due to type mismatch, contributing to the memory leak.The default placeholder type is introduced in a new macro:
PLACEHOLDER_TYPE. An arbitirary value of0is used; the first validtypesGood[]item is used when checking bad parameters.More return codes are checked (e.g. on
wc_HashFree) that were not previously checked.The logic for "is this a valid hash?" when checking the
typesNoImpllist has been revised. It is no longer sensitive to the order of items. It was also probably not fully working as intended anyhow.New hash objects are created and destroyed as appropriate in the "Good type and implemented" tests.
Still outstanding
There's still another
test.cmemory leak in or around the PKCS12 test. See message from full log, below:I will look at this one at a later date unless otherwise advised.
It would be nice to have the hash checks for other platforms to give similar warnings. For now the feature is Espressif-specific.
Full ESP32 Output
For reference:
Fixes zd# n/a
Testing
How did you test?
ESP32 with and without HW encryption, with and without WOLFSSL_SMALL_STACK on ESP-IDF v5.2.
./autogen.sh ./configure --enable-smallstack --enable-all make clean make -j$(nproc) ./wolfcrypt/test/testwolfcryptAnd
./autogen.sh ./configure --enable-all make clean make -j$(nproc) ./wolfcrypt/test/testwolfcryptUpdate:
Tests have been running on my 9-device jig since yesterday. Screen snip of memory shows no memory leak for the default tests running on the 8x ESP32 + ESP8266
Checklist