bugCERTI - Bugs: bug #49986, requestAttributeOwnershipRelease...

 
 

bug #49986: requestAttributeOwnershipRelease followed by negotiatedAttributeOwnershipDivestiture crashes rtig

Submitted by:  Joris Goosen <jorisgoosen>
Submitted on:  Thu 05 Jan 2017 02:45:44 PM UTC  
 
Category:  CERTI Severity:  3 - Normal
Item Group:  Software error Status:  Need Info
Privacy:  Public Assigned to:  JbCh <jb_ch>
Open/Closed:  Open Release:  3.5.0
Reproducibility:  None Fixed Release:  Unknown

Add a New Comment (Rich Markup)
   

You are not logged in

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

 

Tue 10 Apr 2018 08:03:58 AM UTC, comment #5: 

Hello Joris,

Thanks for the feedback, I will try to reproduce a test case on my own.

JbCh <jb_ch>
Project AdministratorIn charge of this item.
Tue 10 Apr 2018 08:02:04 AM UTC, comment #4: 

I am afraid I no longer have access to the code so I can't help you with providing the exact used scenario or a test.

As far as I could gather from the actual specifications of HLA requestAttributeOwnershipRelease can also be followed by negotiatedAttributeOwnershipDivestiture (according to the convoluted graph that is included)

Sorry I can't be of more help.

Joris Goosen <jorisgoosen>
Mon 09 Apr 2018 08:21:27 PM UTC, comment #3: 

For the "Pull" method, a federate which wants the ownership informs the RTI (and the current owner) by sending requestAttributeOwnershipRelease(..). The owner may respond with AttributeOwnershipReleaseResponse(..).

JbCh <jb_ch>
Project AdministratorIn charge of this item.
Mon 09 Apr 2018 08:13:12 PM UTC, comment #2: 

Different methods to transfer the ownership (from the book of Carl Tropper).

1 -> "Push" method: The federate which owns the attribute initiates the ownership exchange by informing the RTI of its willingness to give up the ownership.

2 -> "Pull" method: The federate which wish to take over the ownership of a given attribute sends an acquisition request to the RTI and initiates the process.

For the push, there is two variants (1-a) unconditional or (1-b) negociated (conditional).

(1-a) In the unconditional approach, the owner inform the RTI that it wish to give up the ownership without knowledge of any receivers. The federate can immediately release the ownership by calling the  unconditionalAttributeOwnershipDivestiture

For (1-b), the owner federate makes sure that there is an interested party among the other federates before releasing the ownership. This process starts per a call to negotiatedAttributeOwnershipDivestiture, then the RTI propagate the info to all eligible federate for this ownership by sending "requestOwnershipAssumption". THen if there is a federate interested per the ownership, it can reply with the call "attributeOwnershipAcquisitionIfAvailable".

Joris, can you share your test case illustrating this behavior for further testing of process 1-b)

JbCh <jb_ch>
Project AdministratorIn charge of this item.
Thu 05 Jan 2017 02:55:56 PM UTC, comment #1: 

Aah, it seems that calling negotiatedAttributeOwnershipDivestiture at all will lead to this error.

If I look in the code though the size of the vector IS in fact being set to the right size. The problem is that this is being done only after the assignment is made..
"AnswerDivestiture.setAttributesSize(compteur_divestiture);"

Joris Goosen <jorisgoosen>
Thu 05 Jan 2017 02:45:44 PM UTC, original submission:  

I was testing the transferal of attribute ownership and noticed that for a case where a single attribute was being transferred the RTIG crashes.

In this case, a requestAttributeOwnershipRelease  is followed by a negotiatedAttributeOwnershipDivestiture for the attribute.
This all goes well until way into the governor where:

void NM_Attribute_Ownership_Base::setAttributes(const AttributeHandle& newAttributes, uint32_t rank)

from NM_Classes.hh is invoked:
"void setAttributes(const AttributeHandle& newAttributes, uint32_t rank) {attributes[rank]=newAttributes;}"

However, the vector attributes is not correctly sized to accomodate the new attribute. This leads to an exception.

Workaround is using attributeOwnershipDivestitureIfWanted or unconditionalAttributeOwnershipDivestiture

Joris Goosen <jorisgoosen>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #39953:  OnlyBugFix.patch added by jorisgoosen (3KiB - application/octet-stream - This fixes the problem for me)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jb_ch (Posted a comment)
  • -email is unavailable- added by jorisgoosen (Submitted the item)
  •  

     

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-04-09 jb_ch StatusNone => Need Info
        Assigned toNone => jb_ch
    2017-03-09 jorisgoosen Attached File- => Added OnlyBugFix.patch, #39953

    Back to the top


    Powered by Savane 3.5