kernel mprotecting my stack?
kernel mprotecting my stack?
- Subject: kernel mprotecting my stack?
- From: Cyrus Harmon <email@hidden>
- Date: Tue, 6 Feb 2007 17:47:43 -0800
I'm not sure if this is really a kernel question per se, as it's
motivated by user-space operations, rather than a KEXT or what not,
but I'm getting an error like so:
[Switching to thread 11 (process 5245 thread 0x5803)]
0x90004d8a in syscall ()
(gdb) bt
#0 0x90004d8a in syscall ()
Cannot access memory at address 0xba01b80
Cannot access memory at address 0xba01b7c
where 0xba01b80 happens to be right where I expect my stack to be,
but I find that it's mprotected and I can't read it to figure out
what's going on (or if this is perhaps the original root of the
problem).
We do some mprotection of a block at the bottom of the stack to
detect when we run out of stack, but this doesn't seem to be related
to that.
I should offer the caveat that this code does a number of unorthodox
things, such as:
1. intentionally using protected memory blocks and the associated
signals/mach exceptions that get generated in the normal course of
our GC stuff.
2. we have an odd mix of mach exception handling code and unix signal
handling code. the original version used unix signals, of course, and
I've been migrating bits and pieces over to mach exceptions (and my
own signal emulation stuff that I have more control over). The
motivation for this is that the memory protection stuff I described
above gives gdb fits and the system is basically undebuggable when
trying to do this with only posix-y singals, so we need some mach
exception handling code. The rationale for mixing these with the
posix signals is that we have a ton of code that already deals with
posix signals and it's not clear that trying to move all of the
signal handling (and there's a lot of it, believe me) over to mach
exceptions makes sense.
3. both our posix signal handlers and our mach exception handlers end
up doing a fair amount of work. In particular, we do things like
coordinating stopping all other threads in order to do a garbage
collection on one thread and we do a fair amount of context/
thread_state manipulation to, for instance, save the machine state in
order to pass it on to error handling code when we return from
certain signal handlers.
I'd like to clean this stuff up and do it in as nice of a way
possible, but it seems like there aren't really any easy ways to do
this. The Boehm GC code seems to do a reasonably good job here and
it's not _too_ terribly messy, so perhaps there's some hope.
In any event, there are certainly many areas where this could be
going wrong, but I'm puzzled as to why this particular block of
memory would be mprotected.
Thanks,
Cyrus
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden