Two pieces of fundamental knowledge:
- A local variable with the same name takes preference over the global variable, inside the function/block where the local variable is defined. The same applies to the function parameters.
- When program crashes with signo 11 (SIGSEGV), examine core dump by gdb, to locate where the crash occurs.
However, it took me a few hours before realizing it… I was so scared at signal handling,
case 1: The pointer to a context was defined as a local variable in main(). Now, we want to change the context in signal thread/signal hander, two methods:
- Pass the pointer as an argument when call pthread_create(). // don’t work for signal handler; don’t work for the situation that that the pointer might change (context being destroyed and re-created).
- Move the pointer declaration out of main().
so, I use the 2nd method. however, I made a mistake, leaving the old local variable still there. you can imagine, every time, when a signal is caught, the pointer is NULL.
I think, …It must be related to signal handling, maybe it is incorrect to share the pointer between signal handler and thread, this way..
In signal handler of a customized app, it does something, then SIG_DFL(signo). The usual way is signal(signo, SIG_DFL). As the complier doesn’t complain, I think it is the other way to take the default action.
Will SIGBUS lead to a SIGSEGV? I didn’t find a proof while looking at the kernel code, then turned to a collegue.
he asked: what did GDB say?
I: Do you mean using GDB to trace the signal? How?
he said: At least, GDB can tell you where it crashes. where it crashes, does it say the “ip”?
I realized I need treat it as a normal crash.. then it is so easy, as the system prints ” run fault pid xx tid xx code q ip 0″. it is obvious that the app was trying to access address 0, which is invalid.
the definition of SIG_DFL in signal.h,