[Developers] exit strategies

[Steve White]

Bela,

This was one of those "things I was going to do something about".

Some time earlier this year we were disappointed by this behaviour, so I
investigated it somewhat, seeing how exit() and abort() were used in 
Cactus and thorns.  I don't recall if I posted my report, but here it is:

Use of exit() and abort() in Cactus

exit() is used by several thorns in a raw form sometimes with arbitrary
values, sometimes without even printing an error message.  (note that if a
message is printed by a not-root process, the message won't be seen in the
main stdio)

Only two meaningful, standard values are defined for the argument of exit():
	EXIT_SUCCESS, EXIT_FAILURE. 
These are sometimes used but usually not.  And there are cases of arbitrary
nonsense values being passed.

However, exit() does not trigger a core dump or print an informational
message, and sometimes that is what one really needs.

The most evil thing is a raw call to exit() (with a magic number argument)
which prints no explanatory message.  This necessitates debugging to find
where the code exited.

Likewise, CCTK_VWarn should be preferred to direct calls to CCTK_Exit
or CCTK_Abort.

Let's discuss these possibilites

	1) a parameter that makes any call to CCTK_Exit() with value other
	   than EXIT_SUCCESS to call abort().

	2) To make CCTK_Abort print a message and call abort().

	3) To clean up raw calls to exit() in thorns.

	4) make CCTK_VWarn to pass EXIT_FAILURE to CCTK_Abort if
	   level <= error_level (do in Flesh, PUGH and Carpet)


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

arrangements/AEIDevelopment/TwoPunctures/src/TP_utilities.c:  exit (1);
arrangements/AEIDevelopment/Unfish/src/unfish.c:           exit(1);
arrangements/AEIThorns/BAM_Elliptic/src/Cactus4_utils.c:#define STOP  exit(0);
arrangements/AEIThorns/BAM_Elliptic/src/Cactus4_utils.c:#define ABORT exit(1);
arrangements/AEIThorns/BAM_Elliptic/src/Cactus4_utils.c:#define CORE  exit(2);
arrangements/CactusExternal/FlexIO/src/ffio.c:    exit (1);
arrangements/CactusExternal/FlexIO/src/ffio.c:          exit (1);
arrangements/CactusExternal/FlexIO/src/ffio.c:                  exit (1);
arrangements/CactusExternal/FlexIO/src/ffio.c:                          exit (1);
arrangements/CactusExternal/jpeg6b/src/ansi2knr.c:                      exit(1);
arrangements/CactusExternal/jpeg6b/src/ansi2knr.c:              exit(0);
arrangements/CactusExternal/jpeg6b/src/ansi2knr.c:                      exit(1);
arrangements/CactusExternal/jpeg6b/src/ansi2knr.c:              exit(1);
arrangements/CactusPUGH/PUGH/src/SetupPGH.c:  exit (retval);
arrangements/CactusPUGH/PUGH/src/SetupPGH.c:               exit
arrangements/CactusPUGH/PUGH/src/SetupPGH.c:  exit (retval);arrangements/EUHydro/Whisky_RNSID/src/equil.c:       exit(0);
arrangements/EUHydro/Whisky_RNSID/src/nrutil.c: fprintf(stderr,"...now exiting to system...\n");
arrangements/EUHydro/Whisky_RNSID/src/nrutil.c: exit(1);
arrangements/EUHydro/Whisky_RNSID/src/nrutil.c: void exit();
arrangements/EUHydro/Whisky_RNSID/src/nrutil.c: fprintf(stderr,"...now exiting to system...\n");
arrangements/EUHydro/Whisky_RNSID/src/nrutil.c: exit(1);
arrangements/EUHydro/Whisky_RNSID/src/rnsid.c:               exit(0);

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

src/main/ScheduleInterface.c:    exit(2);
src/comm/CactusDefaultComm.c:  exit (retval);
src/util/ParseFile.c
	:CheckBuf has the useless
	    assert(0);
	    exit(1);

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Drivers overload CCTK_Exit and CCTK_Abort
	Defines Exit and Abort, which just call exit with arbitrary values
arrangements/Carpet/Carpet/src/helpers.cc
arrangements/CactusPUGH/PUGH/src/SetupPGH.c


But it's only called a few places:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

src/comm/OverloadComm.c:  *ierror = CCTK_Exit (*GH, *retval);
src/main/CommandLine.c:  CCTK_Exit (NULL, retval);
src/main/CommandLine.c:              CCTK_Exit (NULL, 2);
src/main/CommandLine.c:  CCTK_Exit (NULL, 0);
src/main/CommandLine.c:  CCTK_Exit (NULL, retcode);
src/main/CommandLine.c:  CCTK_Exit (NULL, 1);
src/main/CommandLine.c:  CCTK_Exit (NULL, 1);
src/main/CommandLine.c:  CCTK_Exit (NULL, 1);
src/main/CommandLine.c:  CCTK_Exit (NULL, 1);
	/* this is how CCTK_VWarn exits -- note it always reports normal exit*/
src/main/WarnLevel.c:    CCTK_Abort (NULL, 0);
	/* this is particularly wierd--in CCTKi_FinaliseParamWarn */
src/main/WarnLevel.c:      CCTK_Abort (NULL, 99);	
src/util/Malloc.c:    /*$CCTK_Abort(NULL);$*/
src/util/Malloc.c:      /*$CCTK_Abort(NULL);$*/
src/util/Malloc.c:    CCTK_Abort(NULL,0);

arrangements/CactusConnect/HTTPD/src/Startup.c:    CCTK_Exit(cctkGH,99);
arrangements/AEIThorns/Nice/src/nice.c:        CCTK_Abort(cctkGH, 1);
arrangements/AEIThorns/Nice/src/nice.c:        CCTK_Abort(cctkGH, 1);
arrangements/AEIThorns/Nice/src/nice.c:        CCTK_Abort(cctkGH, 1);
arrangements/CactusConnect/HTTPD/src/Sockets.c:    CCTK_Abort(cctkGH, EXIT_FAILURE);
arrangements/CactusConnect/HTTPD/src/Sockets.c:          CCTK_Abort(NULL, EXIT_FAILURE);
arrangements/CactusPUGHIO/IsoSurfacer/src/Sockets.c:          CCTK_Abort(NULL, EXIT_FAILURE);
arrangements/CactusPUGHIO/IsoSurfacer/src/Sockets.c:    CCTK_Abort(NULL, EXIT_FAILURE);
arrangements/CactusPUGHIO/IsoSurfacer/src/Sockets.c:    CCTK_Abort(NULL,EXIT_FAILURE);
arrangements/CactusUtils/NaNChecker/src/NaNCheck.c:    CCTK_Abort (cctkGH, 0);
arrangements/CactusUtils/NaNChecker/src/NaNCheck.c:      CCTK_Abort (NULL, 0);



On  5.12.06, Bela Szilagyi wrote:
> As I understand, currently Cactus does "nice" exits, i.e., it calls exit() 
> even if the user thorn is desperate enough to call CCTK_Warn(0, ...);
> 
> While there is a value to niceness, it would be nice to allow (with an extra 
> parameter) for abort() - style exits, such that a core-dump is requested from 
> the system.
> 
> If CCTK_Abort() also calls exit() rather than abort(), perhaps the new 
> aborting parameter could apply to this function.
> 

-- 
Steve White : Programmer
Max-Planck-Institut für Gravitationsphysik      Albert-Einstein-Institut
Am Mühlenberg 1, D-14476 Golm, Germany                  +49-331-567-7625