Re: [certi-dev] Memory issues

[Eric Noulard]

Hi all,

In order to ease memory issue debugging of CERTI I put some option in CMakeLists.txt in order

to be able to compile CERTI with Clang sanitizers:
https://channel9.msdn.com/Events/CPP/C-PP-Con-2014/Sanitize-your-CPP-code

http://clang.llvm.org/docs/AddressSanitizer.html
http://clang.llvm.org/docs/MemorySanitizer.html

The option is OFF by default and its needs clang/clang++ as compilers.

The compilation is Ok but as of today I did not manage to properly blacklist

some generated files (gengetopt, flex etc...).

After reading stric aliasing carefully I don't think
libHLA/MessageBuffer.cc

is suffering from this because we purposely allocate a buffer of uint8_t

i.e.
uint8_t* buffer;

Then we may memcpy it into int16_t, int32_t or int64_t but from my understanding

I think it's safe.

At least

MessageBufferTests passes even with ASan or MSan.

Eric

2015-08-28 4:02 GMT+02:00 David Come <address@hidden>:

Hi.

I have just found some code try to access some uninitialized bytes
Please find attached is the valgrind dump.

I have had a look at libHLA/MessageBuffer.cc and I'm concerned about the code safety with the strict aliasing rule.
See https://channel9.msdn.com/Events/CPP/C-PP-Con-2014/Lightning-Talks-The-Perils-of-Strict-Aliasing for strict aliasing rule.
and http://dbp-consulting.com/tutorials/StrictAliasing.html

There are also many hard coded magic numbers...


I also mention I encountered another bug when using isAttributeOwnedByFederate.
In libRTI/hla-1_3/RTIambassador.cc, in RTI::RTIambassador::isAttributeOwnedByFederate
the rep.getTag()  gives me "RTI_TRUE0" at some point.

I can reproduce the bug, I'll try to figure it tomorrow.
I'm not sure if that issue is linked to the strict aliasing rule

David.

--
CERTI-Devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/certi-devel

--

Eric