bugCERTI - Bugs: bug #29560, rtia::Communications::waitMessage...

 
 

bug #29560: rtia::Communications::waitMessage hangs when receiving an exception message

Submitted by:  Jeroen van IJperen <vyperx>
Submitted on:  Thu 15 Apr 2010 01:16:01 PM UTC  
 
Category: CERTISeverity: 3 - Normal
Item Group: Software errorStatus: Ready For Test
Privacy: PublicAssigned to: Eric NOULARD <erk>
Open/Closed: ClosedRelease: CVS
Reproducibility: Every TimeFixed Release: 3.4.0

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

Sun 30 May 2010 05:44:30 PM UTC, comment #4:

Just checked-in the proposed modification.
I'm OK, putting federate and federation ID even
in the exceptionnal case is no big deal.
We already are in "exceptional" condition.

Nevertheless waitMessage must be enhance,
but that's another issue. In fact the whole
exception handling in CERTI need rework, but I think
we will handle that as another task.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Mon 03 May 2010 06:56:20 AM UTC, comment #3:

Hi Eric,

I figured that adding the federate-id and federation-id wouldn't really add any overhead. Normally they would be included anyway.

To me a 'header' of the following items seems pretty logical:
1) msg_type,
2) federate-id,
3) federation-id, and
4) exception_type

Thanks for the hint on 'cvs diff'. I used WinMerge to create the diff, but that obviously does not take CVS information into account. :)

Jeroen van IJperen <vyperx>
Project Member
Fri 30 Apr 2010 07:16:23 AM UTC, comment #2:

Hi Jeroen,
The solution looks ok, even if it break compat
(we can afford some breakage between 3.3.x and
coming 3.4.x)

However I was wondering if requiring a valid
federate + federation ID wasn't a little too much for
an exceptionnal condition.

Another fix would be to enhance waitMessage in order
to check that a exception "message" was received
and deliver such message to caller.

Caller should then handle this exceptional message properly.
I'll think about that a little more.

As a side note, when you provide a patch the better way to do it is to provide a unified diff patch format (see my version of your patch attached).

You can generate such a patch using "cvs diff -u" [command line]
or the builtin support for "patch" of many tools like Eclipse, TortoiseCVS, ...

(file #20378)

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Thu 29 Apr 2010 07:49:23 AM UTC, comment #1:

I've attached a patch for this, with my proposed solution.

Unfortunatly this may break compatibility between different CERTI versions, but I do believe it's a required fix.

(file #20368)

Jeroen van IJperen <vyperx>
Project Member
Thu 15 Apr 2010 01:16:01 PM UTC, original submission:

In the RTIA for some services the Communications::waitMessage function is used, where it is indicated to wait for the response from a specific federate. (Second parameter (FederateHandle) != 0.)

In these cases, if the service generated an exception on the RTIG, the RTIA will hang.

This can be traced back to the message protocol, which will not include the federate and federation identifiers when an exception is being sent.

Proposed solution: always send federate and federation identifiers in the network messages. (NetworkMessage_RW.cc - NetworkMessage::serialize/deserialize)

Jeroen van IJperen <vyperx>
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 #20378:  bug29560-erk1.patch added by erk (1KiB - text/x-patch - Same patch using unified diff format)
file #20368:  NetworkMessage_RW.cc.patch added by vyperx (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by erk (Updated the item)
  • -unavailable- added by vyperx (Submitted the item)
  • -unavailable- added by vyperx
  •  

    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
    Thu 11 Nov 2010 11:13:36 AM UTCerkOpen/ClosedOpen=>Closed
    Thu 11 Nov 2010 11:13:30 AM UTCerkFixed ReleaseCVS=>3.4.0
    Sun 30 May 2010 05:44:30 PM UTCerkStatusNeed Info=>Ready For Test
      Fixed ReleaseUnknown=>CVS
    Fri 30 Apr 2010 07:16:23 AM UTCerkAttached File-=>Added bug29560-erk1.patch, #20378
      StatusNone=>Need Info
      Assigned toNone=>erk
    Thu 29 Apr 2010 07:49:23 AM UTCvyperxAttached File-=>Added NetworkMessage_RW.cc.patch, #20368
    Thu 15 Apr 2010 01:16:01 PM UTCvyperxCarbon-Copy-=>Added vyperx

    Back to the top


    Powered by Savane 3.1-cleanup1