3

In my application I want to implement backtrace on segmentation fault according to this post: How to generate a stacktrace when my gcc C++ app crashes

But I encountered a problem. My application uses DirectFB for graphics. After I initialize DirectFB by calling DirectFBCreate, the signal handler stops to be called.No matter where the signal handler is registered. Please compare main1, main2 and main3 functions in code bellow:

#include <stdio.h>
#include <execinfo.h>
#include <signal.h>
#include <stdlib.h>
#include <unistd.h>
#include <directfb.h>

void handler(int sig) {
  void *array[10];
  size_t size;

  // get void*'s for all entries on the stack
  size = backtrace(array, 10);

  // print out all the frames to stderr
  fprintf(stderr, "Error: signal %d:\n", sig);
  backtrace_symbols_fd(array, size, STDERR_FILENO);
  exit(1);
}

void baz() {
 int *foo = (int*)-1; // make a bad pointer
  printf("%d\n", *foo);       // causes segfault
}

void bar() { baz(); }
void foo() { bar(); }


int main1(int argc, char **argv) {
  signal(SIGSEGV, handler);   // install our handler

  // if the foo() function is called here,
  // everything works as it should
  foo();

  IDirectFB *dfb = NULL;
  DFBCHECK (DirectFBInit (&argc, &argv));
  DFBCHECK (DirectFBCreate (&dfb));
}

int main2(int argc, char **argv) {
  signal(SIGSEGV, handler);   // install our handler

  IDirectFB *dfb = NULL;
  DFBCHECK (DirectFBInit (&argc, &argv));
  DFBCHECK (DirectFBCreate (&dfb));

  // but calling the foo() function after DirectFBCreate causes
  // that the handler is not called
  foo();
}

int main2(int argc, char **argv) {


  IDirectFB *dfb = NULL;
  DFBCHECK (DirectFBInit (&argc, &argv));
  DFBCHECK (DirectFBCreate (&dfb));

  signal(SIGSEGV, handler);   // install our handler
  // calling the foo() function after DirectFBCreate causes,
  // that the handler is not called
  // no matter the signal handler is registered after DirectFBCreate calling
  foo();
}

I have also tried sigaction function instead of signal function, with the same result.

I have also tried using sigprocmask(SIG_SETMASK, &mask, NULL) to unblock the signal. But this also didn't help (which I expected).

Finally I found this post signal handler not working, which seems to solve similar problem by disabling the library's signal handler by calling zsys_handler_set(NULL);. So I tried signal(SIGSEGV, NULL); and signal(SIGSEGV, SIG_DFL);. Again not succeeded. I didn't find any handler disabling function in DirectFB. Although I found [no-]sighandler argument in DirectFB config and used it, this didn't help neighter (which surprised me a lot).

My question is: If the DirectFB is able to steel my handler, how can I take it back?

Ron
  • 14,674
  • 4
  • 34
  • 47
radimoid
  • 199
  • 1
  • 9
  • From the man page : The effects of signal() in a multithreaded process are unspecified. According to POSIX, the behavior of a process is undefined after it ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by kill(2) or raise(3). – Clonk Sep 01 '17 at 12:25
  • 2
    You can use `strace` to figure out if DirectFB is registering a new signal handler. Look out for calls to `sigaction`. – user2722968 Sep 01 '17 at 14:25

1 Answers1

2

I used strace as mentioned in the comment. I found out that the DirectFB doesn't call sigaction syscall but it blocks some signals, SIGSEGV included. Unblock the signal after DirectFB initialization was the soulution.

// DirectFb initialization
IDirectFB *dfb = NULL;
DFBCHECK (DirectFBInit (&argc, &argv));
DFBCHECK (DirectFBCreate (&dfb));

// Unblock the signal
sigset_t sa_mask;
sigemptyset(&sa_mask);
sigaddset(&sa_mask, SIGSEGV);
sigprocmask(SIG_UNBLOCK, &sa_mask, NULL);
    // here is important to use SIG_UNBLOCK flag
    // not SIG_SETMASK as I did in my question!!!

// Now this causes the handler call
foo();
radimoid
  • 199
  • 1
  • 9