From: Xavier Roche <roche+kml2@exalead.com>
To: linux-kernel@vger.kernel.org
Subject: sigaction's ucontext_t with incorrect stack reference when SA_SIGINFO is being used ?
Date: Mon, 22 Jan 2007 09:57:12 +0100 [thread overview]
Message-ID: <45B47C68.2000903@exalead.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]
Hi folks,
I have a probably louzy question regarding sigaction() behaviour when an
alternate signal stack is used: it seems that I can not get the user
stack reference in the ucontext_t stack context ; ie. the uc_stack
member contains reference of the alternate signal stack, not the stack
that was used before the crash.
Is this is a normal behaviour ? Is there a way to retrieve the original
user's stack inside the signal callback ?
The example given below demonstrates the issue:
top of stack==0x7fffff3d7000, alternative_stack==0x501010
SEGV==0x7fffff3d6ff8; sp==0x501010; current stack is the alternate stack
It is obvious that the SEGV was a stack overflow: the si_addr address is
just on the page below the stack limit.
[-- Attachment #2: stacktest.c --]
[-- Type: text/x-csrc, Size: 2144 bytes --]
/* gcc -g [ -D_REENTRANT ] stacktest.c [ -lpthread ] -o stacktest */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/resource.h>
#include <sys/ucontext.h>
#ifdef _REENTRANT
#include <pthread.h>
#endif
/* the alternative stack reference */
static stack_t ss;
/* this function does nasty things */
static void overflow(void) { overflow(); }
/* test entry point */
static void* threadEntry(void* parg) {
struct rlimit rlim;
/* setup alternative strack for the current thread */
ss.ss_flags = 0;
ss.ss_size = SIGSTKSZ;
ss.ss_sp = malloc(ss.ss_size);
if (ss.ss_sp == NULL) {
abort();
}
if (sigaltstack(&ss, NULL) == -1) {
abort();
}
/* print current stack limit */
if (getrlimit(RLIMIT_STACK, &rlim) == 0) {
const unsigned long page_size = (unsigned long) sysconf(_SC_PAGE_SIZE);
const unsigned long stack_bottom =
(((unsigned long)&rlim-rlim.rlim_cur+page_size-1)/page_size)*page_size;
printf("bottom of stack==%p, alternative_stack==%p\n", (void*)stack_bottom,
(void*)ss.ss_sp);
}
/* do something very nasty */
overflow();
/* we may not reach this point */
return NULL;
}
/* SEGV handler */
static void saHandler(int code, siginfo_t *si, void *sc_) {
void *kenny = (void*) &code;
ucontext_t * const sc = (ucontext_t*) sc_;
printf("SEGV==%p; sp==%p; current stack is the %s\n", (void*)si->si_addr,
(void*)((ucontext_t*)sc_)->uc_stack.ss_sp,
( kenny >= ss.ss_sp && kenny < ss.ss_sp + SIGSTKSZ )
? "alternate stack" : "original stack");
abort();
}
/* main entry point */
int main(void) {
/* catch SEGV with SA_ONSTACK enabled */
struct sigaction s;
memset(&s, 0, sizeof(s));
sigemptyset(&s.sa_mask);
s.sa_flags = SA_SIGINFO | SA_ONSTACK;
s.sa_sigaction = saHandler;
if(sigaction (SIGSEGV, &s, NULL)) {
abort();
}
#ifdef _REENTRANT
/* threaded version */
{
pthread_t t;
pthread_create(&t, NULL, threadEntry, NULL);
pause(); /* wait (almost) endlessly */
}
#else
/* single threaded version */
(void) threadEntry(NULL);
#endif
/* not reached */
abort();
return 0;
}
next reply other threads:[~2007-01-22 9:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-22 8:57 Xavier Roche [this message]
2007-01-23 5:37 ` sigaction's ucontext_t with incorrect stack reference when SA_SIGINFO is being used ? Nicholas Miell
2007-01-24 7:44 ` Xavier Roche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45B47C68.2000903@exalead.com \
--to=roche+kml2@exalead.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.