bugCERTI - Bugs: bug #30349, RTIA (RTIA_network.cc) does not...


bug #30349: RTIA (RTIA_network.cc) does not handle some message (NM_Register_Federation_Synchronization_Point) sent by RTIG.

Submitter:  None
Submitted:  Mon 05 Jul 2010 06:37:02 AM UTC
Category:  CERTI Severity:  * 6 - Security
Item Group:  HLA compliance error Status:  Ready For Test
Privacy:  Public Assigned to:  erk
Open/Closed:  Open Release:  * 3.3.3
Reproducibility:  Every Time Fixed Release:  3.4.0
* Mandatory Fields

Add a New Comment Rich Markup

Thu 11 Nov 2010 11:12:16 AM UTC, comment #4: 

This bug is fixed in 3.4.0
but I keep it open because I think we need more
"semantic" investigation of this issue.

Eric NOULARD <erk>
Group administrator
Mon 09 Aug 2010 02:52:00 PM UTC, comment #3: 

The fix is in CVS.

Note however that I continue to think that the
usage of RFSP service by the Portico example is wrong.

Each offending federate will have his
synchronizationPointRegistrationFailed callback called.

Nevertheless RTIA shouldn't crash anymore.

Eric NOULARD <erk>
Group administrator
Mon 09 Aug 2010 10:22:28 AM UTC, comment #2: 


Now that I did have a closer look at this, here is the situation:

RTIA is not supposed to receive any
NM_Register_Federation_Synchronization_Point message.
However this message is sent because
the TWO federate do call
rtiamb->registerFederationSynchronizationPoint( READY_TO_RUN, "" );

as far as I understand the HLA standard (both 1.3 and 1516)
there should only be a single federate calling the service.

Other should wait for the
announceSynchronizationPoint callback
and then call

In the Portico example both federate call registerFederationSynchronizationPoint thus the second call
fails and an exception is raised in RTIG which send back
a NM_Register_Federation_Synchronization_Point which contains the exception.

So there is 2 problems here:
   A) the exception handling RTIG --> RTIA --> Federate is buggy.
   B) the 2 federates call registerFederationSynchronizationPoint
     (with the same label "ReadyToRun" which is wrong).

A) is a CERTI bug which must be addressed.

B) seems to be a Portico Example misuse of HLA API

Eric NOULARD <erk>
Group administrator
Mon 05 Jul 2010 07:03:32 AM UTC, comment #1: 

Hi there,

I'll try to handle that one.

Eric NOULARD <erk>
Group administrator
Mon 05 Jul 2010 06:37:02 AM UTC, original submission:  

RTIA (RTIA_network.cc) does not handle some message
sent by RTIG.

This can be seen when trying to execute the Portico CPP example using two federates. The simulation crashes with the following error (RTI_EXCEPTION=X):

HLALOG - 1278078405.295837 - Federate - RTItypes.cc> RTI::Exception

> [FederationExecutionAlreadyExists,0x0] - reason= HLALOG -
> 1278078405.296061 - Federate - RTItypes.cc> RTI::Exception
> [FederationExecutionAlreadyExists,0x0] - reason=
> RTIA:: RTIA has thrown RTIinternalError exception.
> RTIA:: Reason: Unknown Message type received from RTIG.
> UN Socket(EmettreUN) : : Broken pipe
> HLALOG - 1278078405.316942 - Federate - RTItypes.cc> RTI::Exception [RTIinternalError,0x0] - reason=NetworkError in tick() while sending TICK_REQUEST: Error while sending UN message.
> terminate called after throwing an instance of 'RTI::RTIinternalError'
> RTI_EXCEPTION variable read, content = X Didn't create federation, it
> already existed Joined Federation as exampleFederate2 Handles
> initialized
> RTIA: Statistics (processed messages)
> List of federate initiated services
> --------------------------------------------------
>       1 Message::GET_OBJECT_CLASS_HANDLE (MSG#112)
>       3 Message::GET_ATTRIBUTE_HANDLE (MSG#114)
>       2 Message::GET_PARAMETER_HANDLE (MSG#118)
> List of RTI initiated services
> --------------------------------------------------
>      47 NetworkMessage::GET_FED_FILE (MSG#84)
>  Number of Federate messages : 9
>  Number of RTIG messages : 48
> * W ** Removing temporary file _RTIA_8044_testfom.fed on RTIA stop.
> RTIA: Federate destroyed
>  TCP Socket  3 : total =      3706 Bytes sent
>  TCP Socket  3 : total =      5442 Bytes received
>  UDP Socket  5 : total =         0 Bytes sent
>  UDP Socket  5 : total =         0 Bytes received



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

Attach Files:

Attached Files
file #20898:  example.zip added by None (7KiB - application/zip)


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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-11-11 erk Fixed ReleaseCVS 3.4.0
    2010-08-09 erk StatusIn Progress Ready For Test
        Fixed ReleaseUnknown CVS
    2010-07-05 erk StatusNone In Progress
        Assigned toNone erk
    2010-07-05 None Attached File- Added example.zip, #20898

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code