[Intel-gfx] [PATCH i-g-t] lib: print the signal name to stderr when handling a signal
Daniel Vetter
daniel at ffwll.ch
Tue Feb 24 02:35:41 PST 2015
On Tue, Feb 24, 2015 at 09:42:04AM +0000, Thomas Wood wrote:
> On 23 February 2015 at 23:54, Daniel Vetter <daniel at ffwll.ch> wrote:
> > On Thu, Feb 19, 2015 at 02:30:17PM +0000, Thomas Wood wrote:
> >> Signed-off-by: Thomas Wood <thomas.wood at intel.com>
> >> ---
> >> lib/igt_core.c | 22 ++++++++++++++++++----
> >> 1 file changed, 18 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/lib/igt_core.c b/lib/igt_core.c
> >> index 75b98f6..adfa597 100644
> >> --- a/lib/igt_core.c
> >> +++ b/lib/igt_core.c
> >> @@ -1303,8 +1303,10 @@ static struct {
> >> static igt_exit_handler_t exit_handler_fn[MAX_EXIT_HANDLERS];
> >> static bool exit_handler_disabled;
> >> static sigset_t saved_sig_mask;
> >> -static const int handled_signals[] =
> >> - { SIGINT, SIGHUP, SIGTERM, SIGQUIT, SIGPIPE, SIGABRT, SIGSEGV, SIGBUS };
> >> +#define SIGDEF(x) { x, #x, sizeof(#x) - 1 }
> >> +static const struct { int number; const char *name; size_t name_len; } handled_signals[] =
> >> + { SIGDEF(SIGINT), SIGDEF(SIGHUP), SIGDEF(SIGTERM), SIGDEF(SIGQUIT),
> >> + SIGDEF(SIGPIPE), SIGDEF(SIGABRT), SIGDEF(SIGSEGV), SIGDEF(SIGBUS) };
> >>
> >> static int install_sig_handler(int sig_num, sighandler_t handler)
> >> {
> >> @@ -1357,8 +1359,20 @@ static void igt_atexit_handler(void)
> >>
> >> static void fatal_sig_handler(int sig)
> >> {
> >> + int i;
> >> +
> >> restore_all_sig_handler();
> >>
> >> + for (i = 0; i < ARRAY_SIZE(handled_signals); i++) {
> >> + if (handled_signals[i].number == sig) {
> >> + write(STDERR_FILENO, "Received signal ", 16);
> >> + write(STDERR_FILENO, handled_signals[i].name,
> >> + handled_signals[i].name_len);
> >> + write(STDERR_FILENO, ".\n", 2);
> >> + break;
> >
> > strsignal() is apparently a neato linux glibc extension. With that
> > simplification instead of the string table this lgtm.
>
> strsignal() returns a description string such as "Terminated" or
> "Segmentation Fault", rather than the signal name, so it doesn't quite
> fit in this context. The function is also not in the list of
> async-signal-safe functions.
It seems to just do an array lookup (at least the array is exposed too),
so pretty sure it actually is signal-safe. But anyway if you add this
explanation to the commit message for why we roll our own them I'm fine
with it. I just wondered.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the Intel-gfx
mailing list