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 ?
Thanks
Ratheesh
----- Original Message ----
From: Michael Smith <email@hidden>
To: Ratheesh Ramachandran <email@hidden>
Cc: Darwin-Kernel List <email@hidden>
Sent: Tuesday, 18 March, 2008 7:26:41 AM
Subject: Re: kernel panic on wakeup from hibernation
On Mar 17, 2008, at 11:46 AM, Ratheesh Ramachandran wrote:
Probably. I have another panic log which has 0x51e591c4.
You pretty clearly have a trashed pointer in your kext; next step is for you to start making heavy use of assert().
= Mike