Re: can I catch an EXC_BAD_ACCESS?
Re: can I catch an EXC_BAD_ACCESS?
- Subject: Re: can I catch an EXC_BAD_ACCESS?
- From: Cyrus Harmon <email@hidden>
- Date: Tue, 27 Jun 2006 16:52:46 -0700
As has been said before, it's portable to everything that purports to
be POSIX compliant. Handling the exception isn't necessarily fast,
but it's faster than checking the address of every memory access.
It's useful for things like informing a garbage collector that a page
has been written to, without explicitly checking each write and for
establishing guard pages on user managed stacks.
The particular example are the CMUCL and SBCL lisp environments, but
I would imagine that other language environments might do use this
behavior as well.
What's incorrect is GDB's handling of the exception, not the code
that expects these sorts of exceptions.
Cyrus
On Jun 24, 2006, at 9:17 PM, Ladd Van Tol wrote:
On Jun 24, 2006, at 4:13 PM, Cyrus Harmon wrote:
Or, the EXC_BAD_ACCESS/SIGBUS might signal a memory protection
violation, which might very well be the intended behavior of the
program in question. One can write a mach exception handler to
handle the EXC_BAD_ACCESS or, a bit more easily, a POSIX-style
(often referred to as a BSD-style) signal handler to handle the
SIGBUS. But then you'll run into problems trying to debug this
because gdb doesn't properly step over them, or ignore them if
trying to do handle pass noprint. It would be nice if Apple would
unbreak gdb such that one could debug programs that rely on
functioning memory protection as part of their strategy for
handling memory management.
It would seem to me that writing code that relies on being able to
catch memory protection violations is incorrect. It's not portable,
and handling the exception is almost certainly not going to be
fast. Further, writing code that stomps on or reads memory that it
doesn't own is generally considered to be bad programming practice.
What situation are you thinking of?
- Ladd
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden