Re: GNU/Hurd portability patches

Hello Thomas,

Thank you for your attention to that anomaly!

10.10.2025 05:59, Thomas Munro wrote:
> [Using this as a general GNU/Hurd problem thread]
>
> An interesting fruitcrow failure:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fruitcrow&dt=2025-09-30%2007%3A28%3A50
>
> TRAP: failed Assert("postgres_signal_arg < PG_NSIG"), File:
> "pqsignal.c", Line: 91, PID: 25731

I've added the following logging:
static void
wrapper_handler(SIGNAL_ARGS)
{
...
         Assert(postgres_signal_arg > 0);
+fprintf(stderr, "!!!wrapper_handler[%d]| postgres_signal_arg: %d, PG_NSIG: %d\n", getpid(), postgres_signal_arg,
PG_NSIG);
         Assert(postgres_signal_arg < PG_NSIG);

and got the following during a successful `make check` run:
2025-10-11 10:55:13.091 BST postmaster[1909] LOG:  starting PostgreSQL 19devel on x86_64-unknown-gnu0.9, compiled by
gcc
 
(Debian 14.2.0-12) 14.2.0, 64-bit
2025-10-11 10:55:13.092 BST postmaster[1909] LOG:  listening on Unix socket "/tmp/pg_regress-Tg7wMt/.s.PGSQL.58928"
2025-10-11 10:55:13.096 BST startup[1915] LOG:  database system was shut down at 2025-10-11 10:55:10 BST
!!!wrapper_handler[1909]| postgres_signal_arg: 20, PG_NSIG: 33
2025-10-11 10:55:13.117 BST postmaster[1909] LOG:  database system is ready to accept connections
!!!wrapper_handler[1910]| postgres_signal_arg: 16, PG_NSIG: 33
!!!wrapper_handler[1918]| postgres_signal_arg: 16, PG_NSIG: 33
...

$ grep -E -o '!!!.*postgres_signal_arg: [0-9]+' .../postmaster.log | grep -E -o '[0-9]+$' | sort | uniq
14
15
16
2
20
30
31

$ kill -l
  1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
  6) SIGABRT      7) SIGEMT       8) SIGFPE       9) SIGKILL     10) SIGBUS
11) SIGSEGV     12) SIGSYS      13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGURG      17) SIGSTOP     18) SIGTSTP     19) SIGCONT     20) SIGCHLD
21) SIGTTIN     22) SIGTTOU     23) SIGIO       24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGINFO     30) SIGUSR1
31) SIGUSR2     32) SIGLOST

Whilst from a failed run, I got:
...
!!!wrapper_handler[1988]| postgres_signal_arg: 30, PG_NSIG: 33
!!!wrapper_handler[1989]| postgres_signal_arg: 30, PG_NSIG: 33
!!!wrapper_handler[3284]| postgres_signal_arg: 14, PG_NSIG: 33
!!!wrapper_handler[3284]| postgres_signal_arg: 28476608, PG_NSIG: 33
TRAP: failed Assert("postgres_signal_arg < PG_NSIG"), File: "pqsignal.c", Line: 94, PID: 3284
!!!wrapper_handler[1980]| postgres_signal_arg: 30, PG_NSIG: 33
!!!wrapper_handler[3278]| postgres_signal_arg: 30, PG_NSIG: 33
!!!wrapper_handler[1980]| postgres_signal_arg: 30, PG_NSIG: 33
!!!wrapper_handler[3278]| postgres_signal_arg: 30, PG_NSIG: 33
postgres(ExceptionalCondition+0x5a) [0x1006af78a]
postgres(+0x70f59a) [0x10070f59a]
/lib/x86_64-gnu/libc.so.0.3(+0x39fee) [0x102b89fee]
/lib/x86_64-gnu/libc.so.0.3(+0x39fdd) [0x102b89fdd]
...
2025-10-11 12:41:53.905 BST postmaster[1980] LOG:  client backend (PID 3284) was terminated by signal 6: Aborted
2025-10-11 12:41:53.905 BST postmaster[1980] DETAIL:  Failed process was running: insert into prtx2 select 1 + i%30, i,
i
           from generate_series(1,500) i, generate_series(1,10) j;

> Is NSIG defined?  Where on the internet can we see the SIGXXX signal
> numbers and the glibc source that is actually used on these systems?
> This has to be handling something installed by pqsignal(), so I guess
> it's probably not the synchronous SIGABRT from abort() expected in
> ExceptionCondition() (assuming that abort() is implemented as
> raise(SIGABRT) in the traditional way, which might not be true), so
> then I guess it must be an asynchronous signal, but which one?

Searching through /usr/include/ gives me:
/usr/include/signal.h:# define NSIG     _NSIG
/usr/include/x86_64-gnu/bits/signum-generic.h:#define _NSIG             (__SIGRTMAX + 1)
/usr/include/x86_64-gnu/bits/signum-arch.h:#define __SIGRTMAX __SIGRTMIN
/usr/include/x86_64-gnu/bits/signum-arch.h:#define __SIGRTMIN   32

> I've so far resisted the urge to spin up a Debian GNU/Hurd box to
> figure any of that out for myself, but maybe someone has a clue...

That's pretty wise — the most frustrating thing with Hurd VM, which I
created as described above, is that it hangs during tests (only 1 out of
5 `make check` runs completes) and killing the hanging processes doesn't
restore it's working state — I have to reboot it (and fsck finds FS errors
on each reboot) or even restore a copy of VM's disk.

Best regards,
Alexander