• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: catching EXC_BAD_ACCESS?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: catching EXC_BAD_ACCESS?


  • Subject: Re: catching EXC_BAD_ACCESS?
  • From: Jonas Maebe <email@hidden>
  • Date: Mon, 21 Nov 2005 15:43:18 +0100


On 21 nov 2005, at 14:53, Brad Parker wrote:

At least on Mac OS X, the init code of libc doesn't turn on (or
possibly explicitly turns off) all FPU exceptions. If you turn them
on, you can catch SIGFPE's as much as you like.

[note - my comments apply only to 64 bit applications. I don't know what
happens for 32 bit apps]


Yes, turning on the fp exception is the easy part. And, the signal
handler gets called. But two problems exist. One is that if sa_flags =
SA_SIGINFO it crashes. It only seems to work if sa_flags is zero. But
if you want the thread state sa_flags needs to be SA_SIGINFO.

At least for 32 bit programs SA_SIGINFO works fine for SIGFPE.

It also seems that changes to the thread state (via args passed to the
signal handler) are ignored.

In other 64 bit "unix-like systems" (read linux), you can change srr0 in
the signal handler and return, changing the flow of the original code.
This doesn't work for me in OS X.

Works fine in 32bit mode for me. See this message (and the two follow- ups by me) for more info and a sample program:
http://lists.apple.com/archives/darwin-development/2004/Jan/ msg00018.html


Note that Safari here gives a ton of "NSURLErrorDomain:-1005" errors when trying to go there, just keep reloading until it gets through.

I've now tried a 64bit version and sure enough, that one always crashes with a SIGBUS when returning from the signal handler, even if the handler doesn't do anything. Warrants a radar, I'd say. I've put the adjusted 64bit version of the test program below (which, as I said, crashes even if you remove all code from "signal_handler"):

***
#include <signal.h>
#include <stdio.h>
#include <ucontext.h>

// check whether we really caught the exception
static int caught = 0;

void signal_handler(int signum, siginfo_t *info, ucontext64_t* sigcontext) {
caught = 1;
// Skip over faulting instruction
sigcontext->uc_mcontext64->ss.srr0 += 4;
// turn off all "exception occurred" flags in fpscr
sigcontext->uc_mcontext64->fs.fpscr &= ~(0xfffc0000);
}



typedef void (*__sighandler_t)();

void install_signal_handler(int signo, __sighandler_t handler) {
  struct sigaction sa;

  sa.sa_handler = (void *)handler;
  sigemptyset(&sa.sa_mask);
  // needed for the ucontext parameter to be available
  sa.sa_flags = SA_SIGINFO;

  sigaction(signo, &sa, NULL);
}


int main() { double a,b,c;

  // install the handler for SIGFPE
  install_signal_handler(SIGFPE, signal_handler);

  // enable FPU exceptions for fpu division by zero, fpu underflow, fpu
  // overflow and fpu invalid operation
  asm volatile("mtfsfi 6,15");

  b = 1.0;
  c = 0.0;

  // trigger an exception
  caught = 0;
  a = b/c;
  printf("caught 1: %d\n",caught);

  // trigger another exception
  caught = 0;
  a = b/c;
  printf("caught 2: %d\n",caught);

  return 0;
}
***


Jonas

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: catching EXC_BAD_ACCESS?
      • From: Jonas Maebe <email@hidden>
References: 
 >Re: catching EXC_BAD_ACCESS? (From: Brad Parker <email@hidden>)

  • Prev by Date: Re: catching EXC_BAD_ACCESS?
  • Next by Date: Re: catching EXC_BAD_ACCESS?
  • Previous by thread: Re: catching EXC_BAD_ACCESS?
  • Next by thread: Re: catching EXC_BAD_ACCESS?
  • Index(es):
    • Date
    • Thread