[BIKESHED] Giving abort(2) a reason

[M. Warner Losh]

In message: <36513.1094632246 at critter.freebsd.dk>
            Poul-Henning Kamp <phk at phk.freebsd.dk> writes:
: 
: A brief talk about malloc's 'A' option on that channel raised again the
: idea that we should have a variant of abort(2) which takes a reason
: which will be logged in the syslog buffers so people can see what is
: wrong rather than just get a core dump.
: 
: Given that we are usually pretty stumped when we get to call abort(2)
: it needs to work without malloc or anything like it and varargs into
: the kernel is not at all in my future.

Only in malloc.  Everywhere else, people have enough state to cope.
Do we really want to have another kernel API just to support malloc
failures?

: My proposal therefore is a system call something like:
: 
: 	abort2(const char *why, int nargs, void **args);
: 
: this would terminate the process like abort(2) and in addition produce
: a message in the syslog buffer along these lines:
: 
:    Aborted $procname pid $pid uid $uid gid $gid.
:    Aborted $procname pid $pid $why $arg1 $arg2...
: 
: A typical usage would be:
: 
: 	if (speed > mach1) {
: 		void *msg[2];
: 
: 		msg[0] = speed;
: 		msg[1] = mach1;
: 
: 		abort2("Supersonic speed not supported", 2, msg);
: 	}
: 
: and the output in syslog would be:
: 
:     Aborted sophwith pid 23 uid 100 gid 100.
:     Aborted sophwith pid 23 Supersonic speed not supported 0x4dd 0x3aa
: 
: Is this workable ?
: 
: Anyone want to try their hands at an implementation ?

That's really ugly.

abort2(const char *fmt, ...)

would be a much better user interface.  Your interface really sucks
from a programming point of view.  If the only goal is to have the
output in syslog, then use syslog directly on the args.  No kernel
APIs are needed:

void
abort2(const char *fmt, ...)
{
	va_list args;

	syslog(LOG_ERR, "Aborted %s pid %d uid %d gid %d\n",
	    __progname, getpid(), getuid(), getgid());
	va_start(ap, fmt);
	vsyslog(LOG_ERR, fmt, ap);
	abort();
}

The work to build the array is likely of similar complexity to the work
needed to build the buffers above.  The connection to syslog is more
complex, I'll grant, but on the whole 99+% of the potential users of
this API would have enough context/state remaining in the program to
be able to do so.

Wanrer