kill -l command shows incorrect list of signals

[Prasad]

Running

kill -l

shows the following output

 1) SIGHUP	 2) SIGINT	 3) SIGQUIT	 4) SIGILL	 5) SIGCHLD
 6) SIGABRT	 7) SIGPIPE	 8) SIGFPE	 9) SIGKILL	10) SIGSTOP
11) SIGSEGV	12) SIGCONT	13) SIGTSTP	14) SIGALRM	15) SIGTERM
16) SIGTTIN	17) SIGTTOU	18) SIGUSR1	19) SIGUSR2	20) SIGWINCH
21) SIGKILLTHR	22) SIGTRAP	23) SIGPOLL	24) SIGPROF	25) SIGSYS
26) SIGURG	27) SIGVTALRM	28) SIGXCPU	29) SIGXFSZ	30) DEBUG
31) ERR	32) RETURN	33) invalid signal number	34) invalid signal number	35) invalid signal number
36) invalid signal number	37) invalid signal number	38) invalid signal number	39) invalid signal number	40) invalid signal number
41) invalid signal number	42) invalid signal number	43) invalid signal number	44) invalid signal number	45) invalid signal number
46) invalid signal number	47) invalid signal number	48) invalid signal number	49) invalid signal number	50) invalid signal number
51) invalid signal number	52) invalid signal number	53) invalid signal number	54) invalid signal number	55) invalid signal number
56) invalid signal number	57) invalid signal number	58) invalid signal number	59) invalid signal number	60) invalid signal number
61) invalid signal number	62) invalid signal number	63) invalid signal number	64) invalid signal number

Apart from showing invalid signal number few signals like

SIGBUS

are not listed in the output

Running the command

kill -SIGBUS <pid>

shows

bash: kill: SIGBUS invalid signal specification

However, executing

kill -30 <pid>

command sends

SIGBUS

to the process

[Prasad]

As I understand the mapping from signal number to string kept in the file

src/bin/bash/signames_haiku.h

The comment in the file suggest that the file is auto-generated using a tool mksignames.

Running the tool shows the following output

prasad@pjoshi:~/sources/Haiku/haiku$ ./generated/objects/linux/x86_64/release/bin/bash/mksignames
/* This file was automatically created by ./generated/objects/linux/x86_64/release/bin/bash/mksignames.
   Do not edit.  Edit support/signames.c instead. */

/* A translation list so we can be polite to our users. */
char *signal_names[NSIG + 4] = {
    "EXIT",
    "SIGHUP",
    "SIGINT",
    "SIGQUIT",
    "SIGILL",
    "SIGTRAP",
    "SIGABRT",
    "SIGBUS",
    "SIGFPE",
    "SIGKILL",
    "SIGUSR1",
    "SIGSEGV",
    "SIGUSR2",
    "SIGPIPE",
    "SIGALRM",
    "SIGTERM",
    "SIGSTKFLT",
    "SIGCHLD",
    "SIGCONT",
    "SIGSTOP",
    "SIGTSTP",
    "SIGTTIN",
    "SIGTTOU",
    "SIGURG",
    "SIGXCPU",
    "SIGXFSZ",
    "SIGVTALRM",
    "SIGPROF",
    "SIGWINCH",
    "SIGIO",
    "SIGPWR",
    "SIGSYS",
    "SIGJUNK(32)",
    "SIGJUNK(33)",
    "SIGRTMIN",
    "SIGRTMIN+1",
    "SIGRTMIN+2",
    "SIGRTMIN+3",
    "SIGRTMIN+4",
    "SIGRTMIN+5",
    "SIGRTMIN+6",
    "SIGRTMIN+7",
    "SIGRTMIN+8",
    "SIGRTMIN+9",
    "SIGRTMIN+10",
    "SIGRTMIN+11",
    "SIGRTMIN+12",
    "SIGRTMIN+13",
    "SIGRTMIN+14",
    "SIGRTMIN+15",
    "SIGRTMAX-14",
    "SIGRTMAX-13",
    "SIGRTMAX-12",
    "SIGRTMAX-11",
    "SIGRTMAX-10",
    "SIGRTMAX-9",
    "SIGRTMAX-8",
    "SIGRTMAX-7",
    "SIGRTMAX-6",
    "SIGRTMAX-5",
    "SIGRTMAX-4",
    "SIGRTMAX-3",
    "SIGRTMAX-2",
    "SIGRTMAX-1",
    "SIGRTMAX",
    "DEBUG",
    "ERR",
    "RETURN",
    (char *)0x0
};

#define initialize_signames()

This seems to be exact list reported on a Linux system, I mean, the signal name and position matches with Linux machine.

AFAIK, this auto-generated list cannot be used, since Haiku uses few propitiatory signals like 'SIGKILLTHR' for example.

So the question I have is, How was the signames_haiku.h generated initially? was it auto-generated? If it was not auto-generated, would it be okay if I manually edit the file and add SIGBUS at 30'th location?

[bonefish]

Replying to Prasad:

This seems to be exact list reported on a Linux system, I mean, the signal name and position matches with Linux machine.

This is rather unsurprising since the tool was built and ran on Linux. I suspect on Haiku it would print better results.

AFAIK, this auto-generated list cannot be used, since Haiku uses few propitiatory signals like 'SIGKILLTHR' for example.

That and not all of the standard signals have the same value.

So the question I have is, How was the signames_haiku.h generated initially? was it auto-generated?

I don't recall. The respective ​commit says hand-edited, but it may have been generated on Haiku.

If it was not auto-generated, would it be okay if I manually edit the file and add SIGBUS at 30'th location?

The array needs quite a bit more editing, since the signal number has changed as well and real-time signals have been added. I guess the easiest solution is to generate the header on Haiku and verify that it looks OK.

[Prasad]

Replying to bonefish:

Replying to Prasad:

This seems to be exact list reported on a Linux system, I mean, the signal name and position matches with Linux machine.

This is rather unsurprising since the tool was built and ran on Linux. I suspect on Haiku it would print better results.

AFAIK, this auto-generated list cannot be used, since Haiku uses few propitiatory signals like 'SIGKILLTHR' for example.

That and not all of the standard signals have the same value.

So the question I have is, How was the signames_haiku.h generated initially? was it auto-generated?

I don't recall. The respective ​commit says hand-edited, but it may have been generated on Haiku.

If it was not auto-generated, would it be okay if I manually edit the file and add SIGBUS at 30'th location?

The array needs quite a bit more editing, since the signal number has changed as well and real-time signals have been added. I guess the easiest solution is to generate the header on Haiku and verify that it looks OK.

Here is the diff of the header file generated on Haiku machine. This diff seems to be correct

prasad@pjoshi:~/sources/Haiku/haiku$ git diff
diff --git a/src/bin/bash/signames_haiku.h b/src/bin/bash/signames_haiku.h
index 8125c7a..784b80a 100644
--- a/src/bin/bash/signames_haiku.h
+++ b/src/bin/bash/signames_haiku.h
@@ -33,6 +33,41 @@ char *signal_names[NSIG + 4] = {
     "SIGVTALRM",
     "SIGXCPU",
     "SIGXFSZ",
+    "SIGBUS",
+    "SIGJUNK(31)",
+    "SIGJUNK(32)",
+    "SIGRTMIN",
+    "SIGRTMIN+1",
+    "SIGRTMIN+2",
+    "SIGRTMIN+3",
+    "SIGRTMAX-3",
+    "SIGRTMAX-2",
+    "SIGRTMAX-1",
+    "SIGRTMAX",
+    "SIGJUNK(41)",
+    "SIGJUNK(42)",
+    "SIGJUNK(43)",
+    "SIGJUNK(44)",
+    "SIGJUNK(45)",
+    "SIGJUNK(46)",
+    "SIGJUNK(47)",
+    "SIGJUNK(48)",
+    "SIGJUNK(49)",
+    "SIGJUNK(50)",
+    "SIGJUNK(51)",
+    "SIGJUNK(52)",
+    "SIGJUNK(53)",
+    "SIGJUNK(54)",
+    "SIGJUNK(55)",
+    "SIGJUNK(56)",
+    "SIGJUNK(57)",
+    "SIGJUNK(58)",
+    "SIGJUNK(59)",
+    "SIGJUNK(60)",
+    "SIGJUNK(61)",
+    "SIGJUNK(62)",
+    "SIGJUNK(63)",
+    "SIGJUNK(64)",
     "DEBUG",
     "ERR",
     "RETURN",

I will verify once and will attach a patch.

[bonefish]

Thanks for the patch. I applied it in hrev44683. I changed the commit message, though. It really doesn't need to be that verbose and shouldn't contain a longish proof of the bug and the fix. However it should contain the scope of the bug (bash, not "userland utilities") and ideally a mention what was wrong and why.