sanitizer / valgrind reports errors with tests

[gocarlos]

memory

if I do (memory sanitizer needs clang):

export CC=/usr/bin/clang
export CXX=/usr/bin/clang++
rm -rf build
mkdir build
cd build
cmake .. -DCOSE_C_USE_SANITIZER=memory
make -j
ctest --verbose

I get use-of-uninitialized-value errors and some tests fail

leak

If I do:

rm -rf build
mkdir build
cd build
cmake .. -DCOSE_C_USE_SANITIZER=leak
make -j
ctest --verbose

I get errors like LeakSanitizer: detected memory leaks and all tests fail
The same can be done with valgrind, see below

undefined

If I do:

rm -rf build
mkdir build
cd build
cmake .. -DCOSE_C_USE_SANITIZER=undefined
make -j
ctest --verbose

I get errors like runtime error: member access within misaligned address 0x55f6e7e1866c for type 'struct cn_cbor', which requires 8 byte alignment

valgrind

If I do:

rm -rf build
mkdir build
cd build
cmake .. -DCOSE_C_VALGRIND_MEMORY_CHECK=ON
make -j
ctest -D ExperimentalMemCheck

I get:

Total Test time (real) =  35.34 sec
-- Processing memory checking output:
1/32 MemCheck: #1: cose_test ........................   Defects: 7
2/32 MemCheck: #2: RFC8152 ..........................   Defects: 152
3/32 MemCheck: #3: aes-ccm ..........................   Defects: 10
4/32 MemCheck: #4: aes-gcm ..........................   Defects: 13
5/32 MemCheck: #5: enveloped ........................   Defects: 8
6/32 MemCheck: #6: encrypted ........................   Defects: 10
7/32 MemCheck: #7: cbc-mac ..........................   Defects: 9
8/32 MemCheck: #8: ecdsa ............................   Defects: 69
9/32 MemCheck: #9: eddsa ............................   Defects: 15
10/32 MemCheck: #10: hmac .............................   Defects: 9
11/32 MemCheck: #11: mac ..............................   Defects: 8
12/32 MemCheck: #12: mac0 .............................   Defects: 8
13/32 MemCheck: #13: hkdf-hmac-sha ....................   Defects: 9
14/32 MemCheck: #14: hkdf-aes .........................   Defects: 9
15/32 MemCheck: #15: aes-wrap .........................   Defects: 9
16/32 MemCheck: #16: ecdh-direct ......................   Defects: 108
17/32 MemCheck: #17: ecdh-wrap ........................   Defects: 155
18/32 MemCheck: #18: sign .............................   Defects: 18
19/32 MemCheck: #19: sign1 ............................   Defects: 18
20/32 MemCheck: #20: corner-cases .....................   Defects: 21
21/32 MemCheck: #21: Memory-mac-hmac ..................   Defects: 5
22/32 MemCheck: #22: Memory-mac-cbc-mac ...............   Defects: 5
23/32 MemCheck: #23: Memory-mac0 ......................   Defects: 5
24/32 MemCheck: #24: Memory-encrypt-gcm ...............   Defects: 5
25/32 MemCheck: #25: Memory-encrypt-ccm ...............   Defects: 5
26/32 MemCheck: #26: Memory-enveloped .................   Defects: 3
27/32 MemCheck: #27: Memory-ecdh ......................   Defects: 5
28/32 MemCheck: #28: Memory-aes-kw ....................   Defects: 5
29/32 MemCheck: #29: Memory-sign0 .....................   Defects: 15
30/32 MemCheck: #30: Memory-sign ......................   Defects: 15
31/32 MemCheck: #31: Memory-sign0-eddsa ...............   Defects: 8
32/32 MemCheck: #32: Memory-sign-eddsa ................   Defects: 8
MemCheck log files can be found here: ( * corresponds to test number)
/home/gocarlos/git/COSE-C/build/Testing/Temporary/MemoryChecker.*.log
Memory checking results:
Memory Leak - 745
Potential Memory Leak - 1
Uninitialized Memory Read - 3

eventually we start to think about converting to C++ to leverage start pointers/references which make memory issues a thing of the past

[jimsch]

smart pointers? I have been thinking of moving to compile as C++ in order to get function decoration to help what I am doing. It might also be helpful to switch to using classes just to make inheritance easier. I don't know how smart pointers are going to interact with the context based allocations. Are you suggesting a custom pointer class?

[gocarlos]

why closing the issue? the suggestion to move to C++ was not the content of the issue (more like a long term thing we could do).

the issue is here that if we run the tests with sanitizers on, then they show leaks and uninitialized usage of variables

ref: https://github.com/google/sanitizers

[jimsch]

Sorry I hit the wrong button

[gocarlos]

dealing with context based allocations is much easier in C++ because of object oriented programming if wished

[gocarlos]

actually I gave it a try to rename all files to cpp and change accordingly in cmake.

already found interesting issues (more restrictive compiler and better warnings with C++):
in recipient.c
value->v.uint -> is an unsigned long
COSE_Algorithm_Direct -> -6
COSE_Algorithm_Direct_HKDF_AES_128 -> -12

	if (key == COSE_Header_Algorithm) {
		if (value->type == CN_CBOR_INT) {
			switch (value->v.uint) {
				case COSE_Algorithm_Direct:
#ifdef USE_Direct_HKDF_AES_128
				case COSE_Algorithm_Direct_HKDF_AES_128:
#endif
#ifdef USE_Direct_HKDF_AES_256
				case COSE_Algorithm_Direct_HKDF_AES_256:

Or I'm missing something?

[jimsch]

No you are not missing anything. This was an error on my part. I will probably make a go at doing cpp files over the weekend.

[jimsch]

The test driver has been switched to use smart pointers in some locations. Templates were pushed into C++ after I really stopped writing code in the language so I did not use a template but a macro. I am sure that this can be changed to use a template at some point.