Re: kernel panic on wakeup from hibernation
Re: kernel panic on wakeup from hibernation
- Subject: Re: kernel panic on wakeup from hibernation
- From: Terry Lambert <email@hidden>
- Date: Tue, 18 Mar 2008 14:18:29 -0700
On Mar 18, 2008, at 1:33 AM, Ratheesh Ramachandran wrote:
My thinking is that this is not a "regular" bad access scenario.
But, something getting triggered by thread-safety issues (ie. the
semaphore_wait's KERN_ABORTED error). I have a memory allocator
function which looks something like this:
void *my_malloc(int size, char *tag) {
lock(); //calls semaphore_wait internally
//get memory
unlock();
}
Notice, I am not checking the result of lock.
If somebody does a thread_terminate() on one of the threads waiting
on lock, thread-safety is compromised ie, multiple threads may
access the critical section. The memory allocator may assign the
same chunk of memory to different threads, one of them may free it,
crashing the others.
Is my reasoning correct ie. consistent with how darwin works ?
What is the best way to handle such a situation ? Should my_malloc()
have returned if lock() returned a KERN_ABORTED ? Should it have
retried ? Will KERN_ABORTED always imply thread termination ?
You are doing this wrong.
See execargs_alloc in xnu in bsd/kern/kern_exec.c for an example of
how to do an allocation using semaphore_wait() without breaking.
Alternately, indicate that your thread us uninterruptible until it
gets the lock (and make sure that you _get_ the lock sometime, or you
will block forever -- better to just do it right).
-- Terry
_______________________________________________
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