Re: Is *that* why debugging backend startup is so hard!?

From: Giles Lean <giles(at)nemeton(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Is *that* why debugging backend startup is so hard!?
Date: 2000-06-27 08:27:26
Message-ID: 2118.962094446@nemeton.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-06-27 08:38:10 Re: Makefile for parser
Previous Message Chris Bitmead 2000-06-27 06:45:35 Re: C exception code