bugCERTI - Bugs: bug #24279, Federate cannot resign after...

 
 

bug #24279: Federate cannot resign after Ctrl-C (UNIX only)

Submitter:  Petr Gotthard <gotthardp>
Submitted:  Tue 16 Sep 2008 06:27:54 PM UTC
   
 
Category:  CERTI Severity:  * 2 - Minor
Item Group:  Software error Status:  Ready For Test
Privacy:  Public Assigned to:  gotthardp
Open/Closed:  Closed Release:  * CVS
Reproducibility:  Every Time Fixed Release:  * 3.3.2
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 14 Oct 2008 03:17:57 PM UTC, comment #8: 

This problem has been solved.

Petr Gotthard <gotthardp>
Group Member
Fri 10 Oct 2008 03:24:15 PM UTC, comment #7: 

I replaced the SIGINT federate-->RTIA by a new CLOSE_CONNEXION message. (I hope I didn't violate any conventions.)

I wonder is any RTIA-->RTIG communication is needed in this case, because the problem reported in this bug report seems to be completely solved.

Petr Gotthard <gotthardp>
Group Member
Fri 19 Sep 2008 08:59:55 AM UTC, comment #6: 

Instead of being "prepared to silently ignore SIGPIPE or NetworkException" it may be better to send CLOSE_CONNEXION is both directions:
 - A sends CLOSE_CONNEXION to B
 - B receives CLOSE_CONNEXION, and starts shutdown (e.g. RTIA sends CLOSE_CONNEXION to RTIG)
 - when shutdown is finished, B sends CLOSE_CONNEXION to A and closes the socket
 - A receives CLOSE_CONNEXION and closes the socket

Petr Gotthard <gotthardp>
Group Member
Thu 18 Sep 2008 10:23:09 AM UTC, comment #5: 

Yes we can.
In fact for NetworkMessage there is
a remainder of a
CLOSE_CONNEXION message
which does not exists for "Message".
I say it's a remainder because RTIG handles the
CloseConnexion NetworkMessage but the RTIA does
not sends it !!

The only trouble with such message is
when will Federate close the socket after
sending CLOSE_CONNEXION message?

When will it be sure the RTIA have processed the message?

My be, once the CLOSE_CONNEXION message is sent
from Federate to RTIA, the Federate should wait
for RTIA to receive the message and close the socket
on its side and be prepared to silently ignore SIGPIPE
or NetworkException.

I think that the appropriate algorithm would be:

Federate sends Message::CLOSE_CONNEXION to RTIA
and prepare itself for Federate<-->RTIA socket closure.

As soons as RTIA receive the Message
1) it sends NetworkMessage::CLOSE_CONNEXION to RTIG
2) prepare itself for RTIA<-->RTIG socket closure
3) once the RTIA<-->RIG socket is closed then
   the RTIA close the Federate<-->RTIA socket

When Federate sees that the socket has been closed by
RTIA it terminates properly.

Socket closure handling may be done in
RTIambassador destructor for the Federate
RTIA destructor for the RTIA

what do you think?

Eric NOULARD <erk>
Group administrator
Thu 18 Sep 2008 09:43:02 AM UTC, comment #4: 

Couldn't be better to define a new FED-->RTIA message to terminate the connection?
I don't like signals much since you often get a different behaviour depending on the user-defined signal mask. If SIGTEM is used as you describe, the user might get an unexpectedly strange behaviour if the SIGTERM is (for some reason) masked.

Petr Gotthard <gotthardp>
Group Member
Wed 17 Sep 2008 09:14:28 PM UTC, comment #3: 

I think that in your testcase the RTIA terminates because
the federate send destroyFederationExecution.

The fact is the previous idea was to terminate RTIA
as soon as the RTIambassador destructor is called.

If you use a federate which does not destroy federation
execution the RTIA will generate an exception because
the Federate terminates without telling it to the RTIA
which "discovers" the fact by a "NetworkException" due
to closed socket.

>>>>>>>>>

RTIA:: RTIA has thrown NetworkError exception.
RTIA:: Reason: Connection closed by client.

>>>>>>>>>


You may try this sequence with the create_destroy federate
from HLA_TestsSuite (or remove the destroy federation part
of your federate).

I think, RTIA should really be able to get a signal
sent in RTIambassador destructor.
We may use SIGTERM may be.

However your patch partially solves the problem
so go-ahead and apply it.
We should keep the bug open+in progress and we will find
a solution for the new secondary issue, since
this is a less annoying error, because the federate
will terminate properly.

We only have a spurious RTIA error.



Eric NOULARD <erk>
Group administrator
Wed 17 Sep 2008 03:41:06 PM UTC, comment #2: 

Patch attached. The problem is when a federate catches SIGINT to resign on Ctrl-C.

Without this patch:
User does Ctrl-C. Both federate and RTIA receive SIGINT. RTIA does set normal_end=1 and terminates. The fedearare wants to resign, but  the RTIA is already down. --> error

With this patch:
User does Ctrl-C. Only federate receives SIGINT. (Because the RTIA inherited the signal mask that was active during fork().) The fedearare resigns and destroys RTIambassador. The RTIA is informed and terminates. --> OK


(file #16510)

Petr Gotthard <gotthardp>
Group Member
Wed 17 Sep 2008 12:56:19 PM UTC, comment #1: 

What do you mean by

"the SIGINT is sent to both federate and RTIA" ?

currently:

  • the federate handle the SIGINT just the

  way he wants.

  • the RTIA install a SIGINT signal handler

  both on Windows and Unix which does nothing
  besides printing a message and setting
  its internal "normal_end" var to 1.

The federate will effectively send a SIGINT to RTIA
as soons as its RTIambassador is destroyed.
The RTI::RTIambassador::~RTIambassador() is doing this.

The only difference I see is that on Unix you have the
notion of "process group" and "session group leader".
http://www.cs.ucsb.edu/~almeroth/classes/W99.276/assignment1/signals.html#Pgrps
You may send a signal to the process group as a whole
if you use kill with a negative value.
If you only fork the child belongs to the process group
of its parent (the federate).

from (ba)sh manual one can read:

To facilitate the implementation of the user interface to job control, the  operating system  maintains the notion of a current terminal process group ID.  Members of this process group processes whose process group ID is equal to the current terminal process  group  ID) receive keyboard-generated signals such as SIGINT.  These processes are said to be in the foreground.

may be we should use setpgrp() inside RTIA in order to avoid
to receive SIGINT from the shell but only wait the
RTIambassador destructor to send the signal.

If you provide a patch I'll be happy to test it :=)

Eric NOULARD <erk>
Group administrator
Tue 16 Sep 2008 06:27:54 PM UTC, original submission:  

What should happen if user terminates (Ctrl-C) the federate?

Currenly the SIGINT is sent to both federate and RTIA, so federate cannot resign after Ctrl-C is invoked. (Federate catches Ctrl-C and sends resign, but RTIA is already down because it also received Ctrl-C.)

I suggest the following: RTIambassador should prevent its child RTIA from receiving SIGINT, thus only the federate will receive SIGINT on Ctrl-C
 - This enables federate to resign on Ctrl-C
 - This does not affect processing of other signals
 - This does not affect RTIA when not executed from RTIambassador

I don't see any reason why someone could be interested in sending SIGINT to federate's RTIA. The RTIA can be correctly terminated once the federate destroys the RTIambassador.

If you agree, I will update RTIambassador accordingly. No changes to RTIA are necessary.

Petr Gotthard <gotthardp>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #16510:  signal.patch added by gotthardp (909B - text/x-patch - Proposed fix.)

 

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 gotthardp (Submitted the item)
  •  

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-04-29 erk Open/ClosedOpen Closed
        Fixed ReleaseNextRelease 3.3.2
    2008-10-14 gotthardp StatusNone Ready For Test
        Fixed ReleaseUnknown NextRelease
    2008-09-17 gotthardp Attached File- Added signal.patch, #16510

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code