bugCERTI - Bugs: bug #23113, Assert violation when invoking a...

 
 

bug #23113: Assert violation when invoking a federation service from a federate service.

Submitted by:  Petr Gotthard <gotthardp>
Submitted on:  Wed 30 Apr 2008 09:35:16 AM UTC  
 
Category: CERTISeverity: 4 - Important
Item Group: Software errorStatus: Fixed
Privacy: PublicAssigned to: Eric NOULARD <erk>
Open/Closed: ClosedRelease: CVS
Reproducibility: Every TimeFixed Release: 3.3.0

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

(Jump to the original submission Jump to the original submission)

Mon 05 May 2008 10:16:38 AM UTC, comment #7:

Thank you, Eric!

There is one "case" I recently found. I think requestClassAttributeValueUpdate() cannot be properly implemented without enhancing the RTIA state machine: the update callback shall not overtake the object discovery.

Petr Gotthard <gotthardp>
Project Member
Mon 05 May 2008 09:46:14 AM UTC, comment #6:

Your patch is checked-in since it pass
my tests and looks good when reading.

Moreover other CERTI user need it because they
call RTI inside callbacks.

The code may even be clearer than before.

However I think we should rather write
down the RTIA state machine which would include
all messages (may be a huge work) because
we may miss some case...
This is a more "long-term" work.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Sat 03 May 2008 03:50:31 PM UTC, comment #5:

Problem is synchronization between federate and RTIA. If there is no synchronization (as was before), the RTIA never knows when the callback is finished, so it doesn't know when to switch the context.

Anyway, I've made a patch (attached) that implements a synchronous communication between RTIA and federate and allows to call a federation service in a tick callback. (Tick within tick is not possible.)
It's similar to what you have proposed, but I still had to introduce an additional overhead (TICK_REQUEST_NEXT). It's not my intention to slow CERTI down ;-), so if someone finds a better solution, I can re-work the patch accordingly.

(file #15599)

Petr Gotthard <gotthardp>
Project Member
Wed 30 Apr 2008 04:12:09 PM UTC, comment #4:

OK I see.
From the performance point of view I would avoid
ANY ACK, alltogether :-) but

in the short term
if it's easier to have a correct behavior with
more ACK I may accept it.

In the long term
I think the "tick" context is the one that should
trigger special handling.
Imagine Federate knows that it is "in tick context"
or "out-of tick context".

When entering "in-tick context" the FederateAmbassador
req->type is TICK

then "in-tick' any RTIA request should be stored
in the in_tick_req (and not 'req').

then the next ACK you get (if any) should be
either a TICK(ACK)
in this case
if (in_tick_req!=NULL)
req = in_tick_req
then you go "out-of-tick" context
either a in_tick_req->type(ACK)
which is OK and you go on 'in-tick context'

When you are "out-of-tick" every check is done as usual.

As far as I understand we don't need to "stack" context
but only to know if we are in-tick or out-of-tick.

I think call tick when in tick context should be forbidden.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Wed 30 Apr 2008 02:26:43 PM UTC, comment #3:

This would be possible if there was a way how to block RTIA until REFLECT_ATTRIBUTE_VALUES is processed.

The RTIA doesn't know when REFLECT_ATTRIBUTE_VALUES finishes, so it cannot stack it until GET_INSTANCE_NAME finishes.

The RTIA currently cannot but should distinguish between the following cases:
(1) GET_INSTANCE_NAME called from reflect callback
tick() --> reflect() --> get instance name()

(2) GET_INSTANCE_NAME called after processing tick()
tick() --> reflect()
get instance name()

I admit that before my tick(n,n) patch the TICK(ACK) was disabled in some cases, so this assertion was avoided. In order to fix the tick(n,n) handling I had to reenable TICK(ACK), so now we get the assertion.
I was not aware there is no ACK to federate services.

I will think about it once again and prepare some patch, but I'm still afraid the ACK to federate services is the only solution.

Petr Gotthard <gotthardp>
Project Member
Wed 30 Apr 2008 11:43:42 AM UTC, comment #2:

I'm not sure that adding ACK for REFLECT is a good idea,
I think we should "stack" pending federate-->RTIA request
such that we may have:

federate --> RTIA: TICK_REQUEST
RTIA --> federate: REFLECT_ATTRIBUTE_VALUES
federate --> RTIA: GET_INSTANCE_NAME
RTIA --> federate: GET_INSTANCE_NAME(ACK)
RTIA --> federate: TICK_REQUEST(ACK)

instead of
federate --> RTIA: TICK_REQUEST
RTIA --> federate: REFLECT_ATTRIBUTE_VALUES
federate --> RTIA: GET_INSTANCE_NAME
RTIA --> federate: TICK_REQUEST(ACK)
RTIA --> federate: GET_INSTANCE_NAME(ACK)

see the closed bug
https://savannah.nongnu.org/bugs/index.php?22292

I put Pierre in CC
however I'm surprised by this issue since Pierre
should have fixed the "re-entrancy" problem:

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Wed 30 Apr 2008 10:03:11 AM UTC, comment #1:

The reason is simple: the protocol between RTIA and federate has no responses.
The communication works like this:
federate --> RTIA: TICK_REQUEST
RTIA --> federate: REFLECT_ATTRIBUTE_VALUES
RTIA --> federate: TICK_REQUEST(ACK)

When someone calls a federate service, it looks like this:
federate --> RTIA: TICK_REQUEST
RTIA --> federate: REFLECT_ATTRIBUTE_VALUES
federate --> RTIA: GET_INSTANCE_NAME
RTIA --> federate: TICK_REQUEST(ACK)
RTIA --> federate: GET_INSTANCE_NAME(ACK)

This causes assert violation since TICK_REQUEST arrived before GET_INSTANCE_NAME.
The only solution I see is to implement ACK's for each federate service. In this case it would look like this:
federate --> RTIA: TICK_REQUEST
RTIA --> federate: REFLECT_ATTRIBUTE_VALUES
federate --> RTIA: GET_INSTANCE_NAME
RTIA --> federate: GET_INSTANCE_NAME(ACK)
federate --> RTIA: REFLECT_ATTRIBUTE_VALUES(ACK) <---- new
RTIA --> federate: TICK_REQUEST(ACK)

What do you think? Is this acceptable from the performance point of view?

Petr Gotthard <gotthardp>
Project Member
Wed 30 Apr 2008 09:35:16 AM UTC, original submission:

User calls tick(), a federate service (e.g. reflect attribute values) is invoked. When processing this callback, the user invokes a federation service (e.g. GET_INSTANCE_NAME).

This results in an assert violation (rep->type != req->type), where rep->type is TICK_REQUEST and req->type is GET_INSTANCE_NAME.

I'm working to fix this issue, but any hints/help is welcome.

Petr Gotthard <gotthardp>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #15599:  tick.diff added by gotthardp (17KiB - text/x-patch - Proposed fix.)

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

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

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

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 02 Jul 2008 08:55:04 AM UTCerkStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
      Fixed ReleaseCVS=>3.3.0
    Mon 05 May 2008 09:46:14 AM UTCerkStatusNone=>Ready For Test
      Assigned toNone=>erk
      Fixed ReleaseUnknown=>CVS
    Sat 03 May 2008 03:50:30 PM UTCgotthardpAttached File-=>Added tick.diff, #15599
    Wed 30 Apr 2008 11:44:15 AM UTCerkDependencies-=>Depends on bugs #22292
    Wed 30 Apr 2008 11:43:42 AM UTCerkCarbon-Copy-=>Added siron

    Back to the top


    Powered by Savane 3.1-cleanup1