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
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 |