public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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;
}

             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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox