Re: kernel mprotecting my stack?
Re: kernel mprotecting my stack?
- Subject: Re: kernel mprotecting my stack?
- From: Michael Smith <email@hidden>
- Date: Wed, 7 Feb 2007 13:35:24 -0800
On Feb 6, 2007, at 5:47 PM, Cyrus Harmon wrote:
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
This means that the memory at that address can't be read. Typically
because you've either freed it out of your address space, or because
it's been busied due to pending I/O, but you suggest another
possibility below.
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).
If the thread is stuck, it is probably waiting on the stack page in
question to become unbusy (e.g. during copyin/out to a stack variable).
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.
Is it possible that you are trying to GC an object that was allocated
on the stack?
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.
Whilst I'm sure it would hurt performance, you could perhaps keep a
log of the last N objects you GC'ed, or add some bounds checking to
your GC code. If you require that all objects participating in GC
are explicitly acquired with malloc, you can use malloc_size() from
<malloc/malloc.h> to catch non-malloc'ed objects (or if you have your
own allocator *and* it tracks outstanding allocations, it should have
an analog).
= Mike
_______________________________________________
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