Tobias Patton <tobiaspattonNOSPAM.shaw.ca> wrote:
Yep.> From reading the manpage for sigaction() and the comments in signal.h, I
> thought I could use the sigcontext pointer that's passed to the signal
> handler to get a pointer to my process's stack.
Yeah, that doesn't look like a valid stack address.> One of the fields in
> this struct is `sc_sp' which I thought was the stack pointer for the
> user-space process that caused the signal. So I wrote some test code to
> examine this value. A typical value for `sc_sp' is 0xfb4b7f0, which
> doesn't look like its in my process's memory space. Sure enough,
> attempting to dererefence this pointer to walk up the stack results in a
> segmentation fault.
Which version of the OS is this? SA_SIGINFO signal handlers didn't work> I've included the test code I wrote, and some sample output. The code
> was compiled using ProjectBuilder 2.1. Any help is appreciated.
correctly until 10.2.
It's not safe to use STL from a signal handler. See> #include <iomanip>
> #include <iostream>
> #include <signal.h>
> void SigActionHandler( int sigNum, siginfo_t* sigInfo, void* sigCtx )
> ( void ) sigInfo;
> struct sigcontext* ctx = ( sigcontext* ) sigCtx;
> std::cout << "Signum : " << sigNum << std::endl
<http://www.opengroup.org/onlinepubs/007908799/xsh/sigaction.html> for a
list of functions that are async-signal safe.
Eric Albert [email]ejalbertstanford.edu[/email]