1

I am having problem in getting my stack trace output to stderr or dumping to a log file. I am running the code in Kubuntu10.04 with gcc compiler (4.4.3). The issue is that in the normal running mode (without gdb), the program does not output anything except 'Segmentation Fault'. I wish to output the backtrace output as in the print statements below. When I run gdb with my application, it comes to the printf/fprintf/(function call) statement, and then crashes with the following statement:

669     {
(gdb) 
670       printf("Testing for stability.\n");
(gdb) 

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff68b1f45 in puts () from /lib/libc.so.6

The strange things is that it works if I call a function within the same file that crashes, it works fine and spews the output properly. But if the program crashes in a function outside this file, it does not print any output. So no printf or file dumping statement or function call gets processed. I am using the following sample code:

void bt_sighandler(int sig, siginfo_t *info,
               void *secret) {

void *trace[16];
char **messages = (char **)NULL;
int i, trace_size = 0;
ucontext_t *uc = (ucontext_t *)secret;

/* Do something useful with siginfo_t */
if (sig == SIGSEGV)
  printf("Got signal %d, faulty address is %p, "
       "from %p\n", sig, info->si_addr, 
       uc->uc_mcontext.gregs[0]);
else
  printf("Got signal %d#92; \n", sig);

trace_size = backtrace(trace, 16);
/* overwrite sigaction with caller's address */
trace[1] = (void *) uc->uc_mcontext.gregs[0];

messages = backtrace_symbols(trace, trace_size);
/* skip first stack frame (points here) */
printf("[bt] Execution path:#92; \n");
for (i=1; i<trace_size; ++i)
  printf("[bt] %s#92; \n", messages[i]);

exit(0);
}


int main() {

/* Install our signal handler */
struct sigaction sa;

sa.sa_sigaction = (void *)bt_sighandler;
sigemptyset (&sa.sa_mask);
sa.sa_flags = SA_RESTART | SA_SIGINFO;

sigaction(SIGSEGV, &sa, NULL);
sigaction(SIGUSR1, &sa, NULL);
/* Do something */
printf("%d#92; \n", func_b());
}

Thanks in advance for any help.

sbi
  • 219,715
  • 46
  • 258
  • 445
gunjan
  • 11
  • 4

6 Answers6

3

Unfortunately you just can't reliably do much of anything in a SIGSEGV handler. Think about it this way: Your program has a serious error and its state (including system level state such as the heap) is in an inconsistent state.

In such a case, you can't expect the OS to magically fix up the heap and other internals it needs in order to be able to execute arbitrary code within your signal handler.

If the SEGV happens in your own code, the good solution is to use the core and fix the root problem. If the core happens in other code via say a shared library, I'd suggest isolating that code in an entirely separate binary and communicate between the two binaries. Then if the library crashes your main program does not.

Mark B
  • 95,107
  • 10
  • 109
  • 188
  • Actually its all a part of big project containing more than 20-30 libraries, and I need to create a handler that can dump the callstack log when anyone of them crashes. So your argument might be correct that one library might not be communicating the heap internals to other (in which the handler is there). I was just wondering why was it printing the callstack in one case (in same library call) and not in another (call from another module/class). – gunjan Mar 22 '11 at 15:02
2

You are supposed to do very little in a signal handler, in principle only access variables of type sig_atomic_t and volatile data.

Doing I/O is definitely out of the question. See this page for gcc:

http://www.gnu.org/s/libc/manual/html_node/Nonreentrancy.html#Nonreentrancy

Bo Persson
  • 90,663
  • 31
  • 146
  • 203
  • But I see lot of people generating output from the handler, for ex from this thread: http://stackoverflow.com/questions/77005/how-to-generate-a-stacktrace-when-my-gcc-c-app-crashes – gunjan Mar 22 '11 at 12:14
0

Try using simpler functions, such as strcat() and write().

  • strcat(), strcpy() work. But I can't print them or dump the information in a file still since fwrite() doesn't work. Also I need to have the backtrace() call working without which I can't get the callstack information. The thing is the code works if I simulate crashing the application from the same file in some other function, but since this is a large project, if I make it crash from some other function in a different file, it does not work. Totally stuck here :( – gunjan Mar 22 '11 at 12:41
  • do not use fwrite. use write(1, buffer, size) (not sure about order of args). 1 is stdout, 2 is stderr. –  Mar 22 '11 at 14:28
0

Is there a reason you can't use valgrind?

fizzer
  • 13,551
  • 9
  • 39
  • 61
  • I have never tried using Valgrind. Actually rather than debugging, I need to create a handler which would dump the log of callstack upon crash. Would try Valgrind to see if it helps me that way. – gunjan Mar 22 '11 at 14:53
0

When the application crashes Linux creates a core dump with the state of the application when it crashed. The core file can be examined using gdb.

If no core file is created try changing core file size with

ulimit -c unlimited

in the same shell and before the program is started. The name of the core file is usually core.PID where PID is the pid of the program. The core file is usually placed somewhere in /tmp or the directory where the program was started.

A lot more info on core files is available on the man page for core. Use

man core

to read the man page.

Tobias
  • 835
  • 1
  • 6
  • 11
0

I managed to get it partially working. Actually I was running the application in 'sudo' mode. Running it in user mode gives me the callstack. However running in user mode disables hardware acceleration (nvidia graphics drivers). To resolve that, I added myself to the 'video' group, so that I have access to /dev/nvidia0 & /dev/nvidiactl. However when I get the access the stack does not get generated anymore. Its only when I am in user mode and hardware acceleration is disabled, the stack is coming. But I can't run my application without hardware acceleration (mean some important functionality would get disabled). Please let me know if anyone has any idea.

Thanks.

gunjan
  • 11
  • 4