bugCERTI - Bugs: bug #34016, Resign then reconnect failure

 
 

bug #34016: Resign then reconnect failure

Submitted by:  Nestor Makhno <makhno>
Submitted on:  Sun 14 Aug 2011 07:08:45 PM UTC  
 
Category: CERTISeverity: 5 - Blocker
Item Group: Software errorStatus: Wont Fix
Privacy: PublicAssigned to: Eric NOULARD <erk>
Open/Closed: OpenRelease: 3.4.0
Reproducibility: Every TimeFixed Release: Unknown

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 02 Sep 2011 09:57:56 PM UTC, comment #5:

After some debugging session I found
that the example code is wrong, in Application2_HLA13.cpp:

//now delete objects and resign

rtiAmb->unsubscribeObjectClass(object_ac_id);

rtiAmb->deleteObjectInstance(object_ac_id,"Delete Aircraft");

rtiAmb->unpublishObjectClass(object_ac_id);

rtiAmb->unsubscribeObjectClass(object_sub_id);

rtiAmb->deleteObjectInstance(object_sub_id,"Delete Submarine");

rtiAmb->unpublishObjectClass(object_sub_id);

is wrong since "object_ac_id" is not an ObjectClassHandle
nor is "object_sub_id" so valid code should be:
rtiAmb->deleteObjectInstance(object_ac_id,"Delete Aircraft");
rtiAmb->unpublishObjectClass(aircraft_id);

rtiAmb->deleteObjectInstance(object_sub_id,"Delete Submarine");
rtiAmb->unpublishObjectClass(submarine_id);

using this updated code, one can do

1) rtig
2) app1
3) app2
3) app2
...
n) app2

without trouble.

Now the problem is the invalid code is misusing the HLA13 handles but CERTI cannot detect that because all thoses
handles are typedef which can be assigned to one another
without even a compiler warning...

So the Nestor trouble is not a real one it's an unfortunate misuse.

The Jan-Patrick problem of a federate crashing is another separate issue we should handle in a separate report.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Thu 01 Sep 2011 01:00:45 PM UTC, comment #4:

Hi All,

Small update.
I now know that there is something wrong in the "unsubscribe"
process which leaves some resigned federate as subscriber
of previously subscribed object classes.

I'm tracking the problem down but the way is paved
with kind of ugly old code I have to clean-up first.

Be patient...

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Wed 31 Aug 2011 09:10:53 AM UTC, comment #3:

Hi all,

Just come back from holiday yesterday and popping the e-mail
stack...
I'll work on your bug report today, stay tuned and thanks for
the report.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Tue 23 Aug 2011 07:12:08 AM UTC, comment #2:

Hi,

I was able to partially solve the problem for my Federate.

I found out that the RTIA was still alive, after my program was already exited. With the help of this bug:
https://savannah.nongnu.org/bugs/?24279
I figured out that the RTIA will be shut down, when the destructor of the rtiAmbassador is called. After some debugging, I figured out that for some reasons, the destructor of the class that holds my rtiAmbassador wasn't called. After I fixed this, the RTIA was destroyed and a re-join was possible without restarting the RTIG.

I said partially, because if the federate crashes, without proper destruction of the rtiAmbassador, the problem will stay? I had this several times during the development of the federate, and it was annoying to restart the RTIG every time. I would highly appreciate some clean-up on the RTIG, in case a Federated disappears without proper resign.

Maybe this is also a solution for the original poster? My federate is HLA1516, and I use the CVS version.

Bye
JPO

Jan-Patrick Osterloh <jpo>
Mon 22 Aug 2011 05:03:33 PM UTC, comment #1:

I can sign this error. I have the same problem, but with 1516. If my client resigns, and joins again, it crashes.

Jan-Patrick Osterloh <jpo>
Sun 14 Aug 2011 07:08:45 PM UTC, original submission:

Trying for the second time to submit this bug. First time just got a blank screen and didn't seem to work.

As discussed in the [certi-dev] mailing list, if an application resigns properly and then reconnects the reconnect is successful but subscribing to object attributes fails.

The example application demonstrates this.

Start RTIG
Start Application1
Start Application2 - creates two objects
..wait 5 seconds
Application2 resigns and exits

Restart Application2 and I get FederateNotExecutionMember when I try to subscribeObjectClassAttributes, although the join has previously succeeded.

The example uses Visual Studio 7.1 (2003) and HLA 1.3. My attempt to provide one with HLA1516 didn't work due to a linker error (createRTIambassador) possibly because of my VS version.

Nestor Makhno <makhno>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #23933:  ResignReconnectHLA13-erk1.zip added by erk (4KiB - application/zip - Updated HLA13 example)
file #23807:  ResignReconnectHLA13.zip added by makhno (9KiB - application/zip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by erk (Posted a comment)
  • -unavailable- added by jpo (Posted a comment)
  • -unavailable- added by makhno (Submitted the item)
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 02 Sep 2011 09:48:49 PM UTCerkAttached File-=>Added ResignReconnectHLA13-erk1.zip, #23933
      StatusIn Progress=>Wont Fix
    Wed 31 Aug 2011 09:10:53 AM UTCerkStatusNone=>In Progress
      Assigned toNone=>erk
    Sun 14 Aug 2011 07:08:45 PM UTCmakhnoAttached File-=>Added ResignReconnectHLA13.zip, #23807

    Back to the top


    Powered by Savane 3.1-cleanup1