Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000081Taste[All Projects] Generalpublic2011-01-12 10:192021-09-16 12:42
Reportermaxime 
Assigned Tomaxime 
PrioritylowSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Summary0000081:

Handling of application termination on native platforms

Description

At the moment native applications have to be terminated with Ctrl-C, which does not guarantee that all ongoing activities are properly stopped (e.g. open GUI queues, open files not flushed, adaclose(),...)

What about adding a SIGINT catcher that would take care of this?

Basically that consists in two additional lines of code in some initialization function:

include <signal.h>

(void) signal(SIGINT, my_handler);

Then inside my_handler we can add Polyorb-specific actions as well as others (DMT, Buildsupport) this way:

void my_handler()
{

include "polyorb_terminate.h"

include "buildsupport_terminate.h"

include "whatever_terminate.h"

exit (0);
}

So that each of us put inside whatever is needed in its own file, generated at orchestration time.

I classified this as low priority - it's not mandatory but mainly for comfort (e.g to avoid the message queues warning when we start an application twice in a row). What do you think ?

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000228)
ttsiodras (administrator)
2011-01-12 11:09

Well, if it is "the message queues already exist" that annoy you, I could also just remove these messages - after all, they are just warnings :-)

(0000230)
hugues (administrator)
2011-01-12 11:14

We should also ensure that the message queues is freed before reusing it. If you flush all pending messages during the init, then this warning can be left only for some verbosity levels

(0000231)
ttsiodras (administrator)
2011-01-12 11:16
edited on: 2011-01-12 11:17

Actually, Cyril's code completely removes the queue if it exists, and re-creates it - so the warning is indeed useless:

// Test if opening the queue failed
if (msgq_id == (mqd_t)-1) {
    // We failed : try to detach a previously existing queue
    perror("create_exchange_queue: first attempt to mq_open()");
    debug_printf(LVL_INFO, "create_exchange_queue: trying to unlink an existing queue...\n");
    // Try to unlink and test if failed
    if(mq_unlink(full_queue_name) == -1) {
(0000235)
ttsiodras (administrator)
2011-01-12 12:56

Shall I do it? Comment out the perror above?

(0000236)
maxime (administrator)
2011-01-12 12:58

Ok to remove this warning, but the point was more general.

If the user code has open files and does not flush them himself, Ctrl-C may loose everything. If it is controling some hardware, maybe some things have to be done to properly shut down, etc.

The point is to avoid shutting down Windows by removing the power plug - I know it works, but we just don't do it for some reasons :-)

(0000732)
maxime (administrator)
2011-05-26 13:14

Coming back on this issue.

I think it is really important to implement this mechanism now.

Messages queues MUST BE CLOSED by their owner before stopping the binary. Otherwise the next user will not be able to run the same binary with his own account (unless he mounts the queues and manually delete them).

In the AADL model, can we add, the same way as we have an Init_Entrypoint, an Exit_point?

If so, could Ocarina generate the code that catches the Ctrl-C and call all the declared cleanup functions prior to exiting ?

(0000736)
hugues (administrator)
2011-05-27 13:41

In AADLv2, we can attach a Deactivate or Finalize entrypoint to a thread or device, not to a process. This entrypoint is executed when a thread is deactivated or finalized.

Finalization goes against the logic of the interface view and RCM AFAICT. In Ada, because of Ravenscar restrictions, you cannot finalize a thread properly. Note that the Ada runtime will close all opened files that it has opened. This excludes things done by C code.

But it could be supported anyway, if we consider we are not finalizing just one thread, but the whole process, i.e. performing an armageddon.

Catching Ctrl-C is linux-specific, not supported obvisouly by ORK+ or RTEMS (no keyboard). But we can do the following

1/ support Finalize_Entrypoint
2/ all finalize_entrypoint are called sequentially in a subprogram as proposed in the first post

a) this function is attached to a signal handler for PO-HI/Ada and PO-HI/C when using Linux
b) this function is attached to gnat_last_chance handler (the ultimate piece of code called when an error is detected, or an exception raised) for ORK+
c) no idea what to do for RTEMS, need to dig the APIs, but it would be surprising there is no way to do that

Note that it will finalize just one node, and will eventually crash the others

Finalizing also ORK+ properly may make sense to switch off properly some interfaces before switching off and rebooting the node. So it would be a good way to support this as well.

Looks like this matches your req, right?

(0000847)
maxime (administrator)
2011-07-10 09:33

It does, let's go for it and let's start with Linux platforms (where it is mostly needed).

At the moment the Initialize_entrypoint is generated by buildsupport for each thread.

On my side shoud I simply add just below : Finalize_Entrypoint => "myfunction_end" and implement the generation of this function ?

(0001415)
ttsiodras (administrator)
2011-12-06 09:30

I have some doubt about hooking SIGINT to complex things: there are only a handful of functions you can call in a signal handler, and e.g. fflush does not qualify.

Basically, the central suggestion that everyone gives about signal handlers is... "don't do much inside it - just set a global flag, and have your main loop poll it".

In our case, the main loop is inside PolyORB - so in principle, if it waits for data arrival using "select", we can avoid doing polling if we use "pselect".

Julien, what do you think?

(0001940)
hugues (administrator)
2012-09-23 20:53

This ticket is assigned to me for quite a long time, what do we do with it?
Shall we close it? unassign it and put it in the list of good ideas to be implemented by someone in the future ?

(0003041)
ttsiodras (administrator)
2017-10-07 08:10

Bumping this up again, since it really made our lives more difficult while preparing the copter demo - Ctrl-C didn't work at all...

Relevant MANDATORY read, if we ever do decide to handle Ctrl-C under Linux:

https://www.cons.org/cracauer/sigint.html [^]
(0003797)
maxime (administrator)
2021-09-16 12:29

I patched POHIC's main function to catch SIGINT and exit(0). This is mandatory to enable gcov to dump the coverage data on disk.


- Issue History
Date Modified Username Field Change
2011-01-12 10:19 maxime New Issue
2011-01-12 11:09 ttsiodras Note Added: 0000228
2011-01-12 11:14 hugues Note Added: 0000230
2011-01-12 11:16 ttsiodras Note Added: 0000231
2011-01-12 11:17 ttsiodras Note Edited: 0000231 View Revisions
2011-01-12 12:56 ttsiodras Note Added: 0000235
2011-01-12 12:58 maxime Note Added: 0000236
2011-05-26 13:08 maxime Description Updated View Revisions
2011-05-26 13:14 maxime Note Added: 0000732
2011-05-26 13:16 maxime Assigned To

=> hugues

2011-05-26 13:16 maxime Status

new => assigned

2011-05-27 13:41 hugues Note Added: 0000736
2011-07-10 09:33 maxime Note Added: 0000847
2011-12-06 09:30 ttsiodras Note Added: 0001415
2012-09-23 20:53 hugues Note Added: 0001940
2013-10-28 20:33 hugues Assigned To

hugues => maxime

2017-10-07 08:10 ttsiodras Note Added: 0003041
2021-09-16 12:29 maxime Note Added: 0003797
2021-09-16 12:37 maxime Status

assigned => resolved

2021-09-16 12:37 maxime Resolution

open => fixed

2021-09-16 12:42 maxime Status

resolved => closed



Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker