backtrace problem in signal-handler

Américo Wang xiyou.wangcong@gmail.com
Thu Jan 14 15:24:00 GMT 2010


On Thu, Jan 14, 2010 at 10:22:49PM +0800, Tianwei wrote:
>Hi, all,
>   I do not know if post the problem into right list, but I really
>hope you can give me some suggestions for my problems.
>
>Now I wrote a PMU profiling tool to monitor programs, such as httpd
>using the LD_PRELOAD mechanism.  The tool is a self-monitoring
>one which means that it reads information in program's signal-handler.
>   Now I also want to get its backtrace in the signal-handler, so I
>wrote some code as:
> static void signal_handler(int sig, siginfo_t *info, void *context) {
> void *stack_trace[10];
>  size = backtrace(stack_trace, 10);
>...........
>}
>
...
>Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
>Now at time/unix/time.c:92 is a  "gmtime_r(&tt, &tm)", It seems that
>inside this glibc function, it's interrupted with PMU, and then enter
>the signal-handler,
>finally when the signal-handler try to walk through the stack and get
>the backtrace, it will meet segmentation fault problem.  My current
>guess is that before entering the signal-handler , the stack is
>already corrupted , which we can see even gdb can not get the full
>backtrace as indicated by "Backtrace stopped: previous frame inner to
>this frame (corrupt stack?)". But I do not know why this will fail. I
>read that both the backtrace and libunwind are asychn-signal-safe, It
>should be safe to use it.
>

That is because the kernel changed it, kernel will alter the stack frame
before entering the signal handler.

But sorry, I don't have a solution for this, you may want to hear
from other experts here.

-- 
Live like a child, think like the god.
 



More information about the Libc-help mailing list