bugCERTI - Bugs: bug #14850, CERTI only transmits long int...

 
 

bug #14850: CERTI only transmits long int values that fit in 32 bits

Submitter:  None
Submitted:  Mon 24 Oct 2005 06:09:19 PM UTC
   
 
Category:  CERTI Severity:  * 3 - Normal
Item Group:  Software error Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Release:  * Unknown
Reproducibility:  Every Time Fixed Release:  3.3.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 02 Jul 2008 09:05:04 AM UTC, comment #5: 

This bug is very old and is not reproducable
with current CERTI version.

Eric NOULARD <erk>
Group administrator
Tue 21 Feb 2006 06:14:05 PM UTC, comment #4: 

A little further probing has proven me wrong.  The point of failure seems to be when an Object attempts to send its ObjectHandle.  When I examined the value of the ObjectHandle, I found it to be in the vicinity of the values of the addresses of various objects in memory.  I cannot easily tell, but I suspect that the ObjectHandle is being set to a memory address cast to unsigned long.  Of course, on a 64 bit machine, a memory address is not bound by 0xffffffff, and indeed the value is considerably larger - hence the failed assertion.

Unfortunately, I can't find anywhere in the code where an ObjectHandle might be set to an improper value.  All calls to setHandle seem to be given sane values - either copies from other ObjectHandles, or with a rising count starting at 1.  Perhaps with your greater familiarity with the code you might be able to discover where such a large value might be set.

Ian Zeilstra <sptrashcan>
Mon 20 Feb 2006 05:31:45 PM UTC, comment #3: 

I am sorry to have taken so long to return to this issue.  Given that the RTI specification requires that a ULONG be 32 bits, I would say that the assertion is justified.  I don't know enough about HLA/RTI to offer a better alternative - CERTI is my first brush with the technology.  The most correct fix would seem to be to change the code of the Billard example to use uint32_ts instead of unsigned longs.  It might also be handy to explain the reason for this width restriction in a comment in the example code, as a shocking amount of production code begins its life as copy-paste from examples!

If I have the opportunity, I will make the modifications to Billard myself and send in a patch.

Ian Zeilstra <sptrashcan>
Sun 30 Oct 2005 02:43:21 PM UTC, comment #2: 

Sorry, I forgot to log in, I'm the poster of comment #1.

Benoit BREHOLEE <breholee>
Sun 30 Oct 2005 02:35:22 PM UTC, comment #1: 

I understand what you expect, but unless I'm wrong, appendix C.2.5 of the RTI-NG documentation says RTI::ULONG [RTI::LONG] should be "platform-independent reference to 4-byte unsigned [signed] integer". So, it looks to me the exchange of 64-bit integers are not really supported by HLA (at least not with natural long ints) : federates may use them but should only send 32-bit integers, since other federates may run on 32-bit or lower machines, and 32 bits is the minimum for a long int.

Previously CERTI just didn't accept 64-bit machines at all, so I changed that to the current way: long ints may be 64 bit long but the sent values have to fit in the 32-bit interval. Probably throwing an exception somewhere in the HLA service would be better than this assertion.

About using uint32_t: well, yes that's actually the type we expect, but if somewhere a 64-bit long int is converted to 32 bits and some data is lost, the fact that something wrong happened should appear. Currently it's an assert, as I said that's not the best solution.

This current choice is based on the information I have on HLA. Of course if you have other information (discussions/updates on this subject, what other RTIs do, etc.) please tell me.

Anonymous
Mon 24 Oct 2005 06:09:19 PM UTC, original submission:  

When running the Billard test on an x86_64 architecture computer, the assertion on line 109 of MessageBody.cc, regarding the size of val, fails.  This assertion assures that the unsigned long argument val is less than 0xffffffff, in other words fits into 32 bits.  The following code breaks val into four unsigned chars.  Unfortunately, on a 64 bit architecture an unsigned long is eight bytes.  While this bug can be fixed in a number of ways (changing the loop counter to 7, replacing unsigned long with uint32_t), I cannot say which would preserve the overall function of the system, or whether other changes would have to be made.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by erk (Posted a comment)
  •  

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-07-02 erk StatusNeed Info Invalid
        Open/ClosedOpen Closed
        ReleaseNone Unknown
        Fixed ReleaseNone 3.3.0
    2006-04-14 breholee Assigned tobreholee None
    2005-11-15 breholee Item GroupHLA compliance error Software error
        StatusNone Need Info
        SummaryCERTI is not 64-bit compatible CERTI only transmits long int values that fit in 32 bits
    2005-10-30 breholee Item GroupSoftware error HLA compliance error
        Assigned toNone breholee

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code