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

 
 

bug #34016: Resign then reconnect failure

Submitter:  Nestor Makhno <makhno>
Submitted:  Sun 14 Aug 2011 07:08:45 PM UTC
   
 
Category:  CERTI Severity:  * 5 - Blocker
Item Group:  Software error Status:  Wont Fix
Privacy:  Public Assigned to:  erk
Open/Closed:  Open Release:  * 3.4.0
Reproducibility:  Every Time Fixed Release:  * Unknown
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group administrator
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>
Group administrator
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>
Group administrator
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 Files:
   
   
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
  • -email is unavailable- added by erk (Posted a comment)
  • -email is unavailable- added by jpo (Posted a comment)
  • -email is unavailable- added by makhno (Submitted the item)
  •  

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-09-02 erk Attached File- Added ResignReconnectHLA13-erk1.zip, #23933
        StatusIn Progress Wont Fix
    2011-08-31 erk StatusNone In Progress
        Assigned toNone erk
    2011-08-14 makhno Attached File- Added ResignReconnectHLA13.zip, #23807

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code