Valgrind reports memory leak on Linux

General
#1

Hi cryptlex team,

Thanks for a great product. When checking our cryptlex-integrated product (with version 3.7.1) with Memcheck (from Valgrind) on Ubuntu 16.04 x86_64 Linux we get reported leaks from ActivateLicense().

Here’s a small repro:

#include <LexActivator.h>
#include <cassert>

int main() {
  char const *const key = /*a valid product key*/;
  char const *const productId = /*a valid product id*/;
  char const *const productData = /*a valid product data*/;

  assert(SetProductData(productData) == LA_OK);
  SetProductId(productId, LA_USER);
  assert(SetLicenseKey(key) == LA_OK);
  assert(ActivateLicense() == LA_OK);
  assert(IsLicenseGenuine() == LA_OK);
  return 0;
}

With appropriate values, the executable runs without triggering any assert. Memcheck complains:

==9066== 72 bytes in 1 blocks are definitely lost in loss record 194 of 526
==9066==    at 0x4030052: calloc (vg_replace_malloc.c:752)
==9066==    by 0x4E06956: ??? (in /usr/lib/x86_64-linux-gnu/libnss3.so)
==9066==    by 0x4E06A18: ??? (in /usr/lib/x86_64-linux-gnu/libnss3.so)
==9066==    by 0x4E06598: ??? (in /usr/lib/x86_64-linux-gnu/libnss3.so)
==9066==    by 0x4DFA5AA: ??? (in /usr/lib/x86_64-linux-gnu/libnss3.so)
==9066==    by 0x4DFF415: ??? (in /usr/lib/x86_64-linux-gnu/libnss3.so)
==9066==    by 0x4DA7A44: ??? (in /usr/lib/x86_64-linux-gnu/libnss3.so)
==9066==    by 0x4DA80BD: NSS_InitContext (in /usr/lib/x86_64-linux-gnu/libnss3.so)
==9066==    by 0x4B0F4B4: ??? (in /home/tom/Downloads/LexActivator/3.7.1/Linux/libs/gcc/amd64/libLexActivator.so)
==9066==    by 0x4B0FBA4: ??? (in /home/tom/Downloads/LexActivator/3.7.1/Linux/libs/gcc/amd64/libLexActivator.so)
==9066==    by 0x4B112BF: ??? (in /home/tom/Downloads/LexActivator/3.7.1/Linux/libs/gcc/amd64/libLexActivator.so)
==9066==    by 0x4B0D2F5: ??? (in /home/tom/Downloads/LexActivator/3.7.1/Linux/libs/gcc/amd64/libLexActivator.so)
==9066== 
==9066== 72 bytes in 1 blocks are definitely lost in loss record 195 of 526
==9066==    at 0x4030052: calloc (vg_replace_malloc.c:752)
==9066==    by 0x92DE216: ??? (in /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so)
==9066==    by 0x92DE2D8: ??? (in /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so)
==9066==    by 0x92DDE58: ??? (in /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so)
==9066==    by 0x92DC2AE: ??? (in /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so)
==9066==    by 0x92D49A9: ??? (in /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so)
==9066==    by 0x4DCD53B: ??? (in /usr/lib/x86_64-linux-gnu/libnss3.so)
==9066==    by 0x4DCDB99: ??? (in /usr/lib/x86_64-linux-gnu/libnss3.so)
==9066==    by 0x4DDABCE: SECMOD_LoadModule (in /usr/lib/x86_64-linux-gnu/libnss3.so)
==9066==    by 0x4DDAD88: SECMOD_LoadUserModule (in /usr/lib/x86_64-linux-gnu/libnss3.so)
==9066==    by 0x4B0F5AC: ??? (in /home/tom/Downloads/LexActivator/3.7.1/Linux/libs/gcc/amd64/libLexActivator.so)
==9066==    by 0x4B109D9: ??? (in /home/tom/Downloads/LexActivator/3.7.1/Linux/libs/gcc/amd64/libLexActivator.so)

==9066== LEAK SUMMARY:
==9066==    definitely lost: 144 bytes in 2 blocks

I’m not especially concerned about this reported leak, because the byte-count doesn’t increase with additional calls to cryptlex functions (eg, ActivateLicense or IsLicenseGenuine), but it is annoying. I guess it’s some lazily-initialized static data?

Thanks for your help,
Tom

#2

One more thing: I said this leak was happening in ActivateLicense, yet the memcheck stacktraces don’t point to this. The reason I deduced this was by running in a debugger and breaking on calls to NSS_InitContext or SECMOD_LoadUserModule, all of which originate from the ActivateLicense call in main.

I also tested this on GCC and Clang (various versions) and got the same leak report.

Cheers,
Tom

#3

Hello Tom,

Thanks for reporting the issue.

We have also observed this during our testing, it’s most probably caused by the third party libnss library, and hence we can’t do much about it. But as you correctly pointed out that the leak doesn’t increase with repeated calls, hence it’s not a major concern.

Regards,
Adnan