certi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [certi-dev] Memory issues


From: Eric Noulard
Subject: Re: [certi-dev] Memory issues
Date: Fri, 28 Aug 2015 10:21:39 +0200



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.

Hi David,

Thanks I can reproduce that on my side with billard and valgrind.
In fact you can reproduce that with any test federate and the error is trigerred each time by the sending
of Join Federation Execution message.

i.e;:

You can try:
$ valgrind CertiTestFederate-HLA13 -n whatever
or
$ valgrind CertiTestFederate-IEEE1516_2000 -n what
or
$ valgrind CertiTestFederate-IEEE1516_2010 -n what

I'll have to dig into it because I don't really understand why valgrind is telling that this area is "unitialized"
since memory inside MessageBuffer do get memset() to 0 upon creation.

So either it is a false positive.
Or there is something I miss.... :-)


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


I'll read that carefully but the only place we do possible non strict aliasing is in the macro
for swapping bytes which should only happen in mixed-endian environment.
Is it your case?

Otherwise the test for message buffers "MessageBufferTests" does not trigger any valgrind issue.
This may simply means that this test is not exhaustive...




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.

did you test whether if the message was Tagged in the first place before trying
to consult the tag?

see rep.isTagged()

may be BasicMessage class should be fixed in order to initialize strings member
(e.g. tag and wtag in your case) to default values in the default protected constructor.
 

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

I doubt it, but who knows... :-)

Thank you very much for hunting those bugs.
 
--
CERTI-Devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/certi-devel




--
Eric

reply via email to

[Prev in Thread] Current Thread [Next in Thread]