Subject: Messages with exit-signal

From: [email-masked] (Niels M�ller)
Date: 15 Mar 2001 16:40:39 +0100

I'm just updating lsh and lshd to use the current signal-related
requests. Two questions:

1. What should I do with unknown signal numbers? I.e. if the OS
   delivers a signal that my implementation doesn't particularly know
   about.

Some options are:

  Don't send any message at all.
  
  Use the empty string for the signal name.
  
  Use a local signal name like "[email-masked]".
  
  Use a local signal name like "[email-masked]".
  
  Do the config.guess-hack, using a name like
  "[email-masked]". 

I want something simple, so I don't want to go for anything more
complex than the first three alternatives unless there is a real
chance that it will be both useful and interoperable. I think I'd
prefer the second alternative, using an empty string to represent
unknown signals. Advice?

2. What should the accompanying message look like?

Some of the alternatives are

  "Segmentation fault" (i.e. whatever strerror returns)
  "Segmentation fault (core dumped)"
  "Process died: Segmentation fault"

I think I'd prefer the first. If the client chooses to display the
message, it has to add some information anyway in order to clearly
indicate that the message originated at the remote end, so it seems
natural to let the client be responsible for making the message look
pretty and only send the information that the client can't figure out
by itself, i.e. only send the string returned by strerror.

/Niels

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 15 Mar 2001 17:50:11 -0500 (EST)

>   "Process died: Segmentation fault"

You won't get these strings from strerror, because signals are not error
numbers.  You pretty much have to come up with them yourself.  See, for
example, sh.init.c in tcsh.

The message with " (core dumped)" is not merely an alternate form; it's an
indication that a core file was actually produced.  This is provided as a
bit in the process status returned by wait().  It may be an implementation
decision whether to make this information visible to the client; some
implementations or sites may prefer not to report this for security
reasons. 

> by itself, i.e. only send the string returned by strerror.

This reasoning clearly eliminates the third variant; the "Process died:"
part is superfluous.  The " (core dumped)", on the other hand, is _not_
information the client can get elsewhere, since even the concept is
UNIX-specific.  IMHO, auxillary information like this should be included
with the signal message.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 15 Mar 2001 18:10:40 -0500

The exact message sent is a local issue, up to the implementation.

That said, I'll digress with..

> example, sh.init.c in tcsh.

Many systems implement strsignal() (just checked BSD, Linux, and
solaris).

				 - Bill

---

From: [email-masked] (Niels M�ller)
Date: 16 Mar 2001 11:24:28 +0100

> example, sh.init.c in tcsh.

Ooops. I meant strsignal (or _sys_siglist on older systems).

> The " (core dumped)", on the other hand, is _not_ information the
> client can get elsewhere, since even the concept is UNIX-specific.
> IMHO, auxillary information like this should be included with the
> signal message.

There's a "boolean core dumped" field in the "exit-signal" request, so
this information can indeed be added to the message by the client.

/Niels

---

From: [email-masked] (Niels M�ller)
Date: 16 Mar 2001 11:30:05 +0100

> The exact message sent is a local issue, up to the implementation.

Different conventions leads to ugliness when interoperating. If a
client expects messages using the "Segmentation fault" convention, and
receives "Process died: Segmentation fault (core dumped)" from the
server, it will likely display the following message to the client:

Remote process died: Process died: Segmentation fault (core dumped) (core dumped)

which isn't pretty. But I agree it's not a terribly important issue.

I believe other problem is more important: What to send for unknown
signals? Unless I get any contrary information, I'll use the empty
string and hope that other implementations can deal with that.

/Niels