Re: Is *that* why debugging backend startup is so hard!? - Mailing list pgsql-hackers

From Giles Lean
Subject Re: Is *that* why debugging backend startup is so hard!?
Date
Msg-id 2118.962094446@nemeton.com.au
Whole thread Raw
In response to Is *that* why debugging backend startup is so hard!?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Needless to say I find this braindead in the extreme.

Wow, definitely braindead.  Trapping some of them on systems that can
programmatically generate a stack backtrace might be useful -- it
would help reporting what happened.

Blocking them and continuing seems about the most dangerous thing that
could be done; if we've just got SIGSEGV or similar the code is
confused isn't to be trusted to safely modify data!

> Will anyone object if I change the signal masks so that we never
> ever block SIGABRT, SIGILL, SIGSEGV, SIGBUS, SIGTRAP, SIGCONT,
> SIGSYS?  Any other candidates?  Are there any systems that do not
> define all of these signal names?

I'd expect these everywhere; certainly they're all defined in the
"Single Unix Specification, version 2".  Some of them don't exist in
ANSI C, if that matters.

Usually it's easy enough to wrap code that cares in

#ifdef SIGABRT
...
#endif

so when/if a platform shows up that lacks one or more it's easy to
fix.

Potential additions to your list:

SIGFPE
SIGSTOP (can't be blocked)

Regards,

Giles



pgsql-hackers by date:

Previous
From: Chris Bitmead
Date:
Subject: Re: C exception code
Next
From: Tom Lane
Date:
Subject: Re: Makefile for parser