Re: GNU/Hurd portability patches

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Alexander Lakhin <[email protected]>
To: Thomas Munro <[email protected]>
To: Michael Banck <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: [email protected]
Subject: Re: GNU/Hurd portability patches
Date: Sat, 11 Oct 2025 15:00:00 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+hUKGJE_moUF74c97GkoP6RaknRMoeFOednXe2FyXnS_bOTFQ@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CA+hUKGJE_moUF74c97GkoP6RaknRMoeFOednXe2FyXnS_bOTFQ@mail.gmail.com>

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

view thread (50+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: GNU/Hurd portability patches
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox