Kernel panic help - kernel controls?
Kernel panic help - kernel controls?
- Subject: Kernel panic help - kernel controls?
- From: Greg <email@hidden>
- Date: Fri, 22 Jun 2007 01:46:17 -0400
Thanks Rob, I think I have everything set up nicely now. My
development machine is an intel mac and my test machine is a powerpc
based computer, so do I understand correctly that I should only deal
with the PPC version of the kernel (on both computers?). That's what
I'm doing right now and it seems to be working.
Since I no longer think this is a kauth issue I've changed the
subject of this email to reflect that.
Now the backtrace gives a lot more information and I also used the
"showcurrentstacks" macro. I'm not really sure what any of it means
but maybe somebody on the list can help me decipher what it means...
I'm not positive but I think it most likely has to do with how I'm
using the kernel control stuff to communicate with my user-land
daemon. I do not have much experience in using the kernel control
stuff and there isn't much documentation on it, I'm going of some
sample code and Apple's "NKE programming guide".
Here is what I have set up:
I have a single kernel control registered, to this kernel control the
daemon establishes two connections, one for sending data on and the
other for receiving it asynchronously from the KEXT (each in its own
thread in the daemon).
In my callback function for sending data I first "lock" it using
atomic integers just to make sure that its code is being executed by
only a single thread at a time. I call mbuf_copydata() on the passed
in mbuf_t object and copy mbuf_len() amount of data into a buffer I
allocated. I then call mbuf_freem() on it.
Everything will work just fine for a while, but after connecting and
reconnecting the daemon to the KEXT several times, or simply after
waiting for a while and doing random stuff, a kernel panic will
occur. It does not occur in the same way each time, sometimes just
clicking on another window can cause it. Also, the backtrace is not
always the same. Also, please remember that I am not positive that
kernel controls are what is causing this, it is just the most likely
candidate because the rest of the code I understand fairly well and
do not see any problems with it.
Here is the detailed output from gdb's "bt" and "showcurrentstacks"
commands:
--------------------
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0003fe3c in zalloc_canblock (zone=0xe3ed50, canblock=1) at /
SourceCache/xnu/xnu-792.17.14/osfmk/kern/zalloc.c:640
640 /SourceCache/xnu/xnu-792.17.14/osfmk/kern/zalloc.c: No such
file or directory.
in /SourceCache/xnu/xnu-792.17.14/osfmk/kern/zalloc.c
(gdb) bt
#0 0x0003fe3c in zalloc_canblock (zone=0xe3ed50, canblock=1) at /
SourceCache/xnu/xnu-792.17.14/osfmk/kern/zalloc.c:640
#1 0x0002bc34 in kalloc_canblock (size=12, canblock=0) at /
SourceCache/xnu/xnu-792.17.14/osfmk/kern/kalloc.c:256
#2 0x002b15a8 in IOMalloc (size=12) at /SourceCache/xnu/
xnu-792.17.14/iokit/Kernel/IOLib.c:153
#3 0x002ba618 in IORegistryIterator::enterEntry (this=0x1cf4e00,
enterPlane=0x1a74d00) at /SourceCache/xnu/xnu-792.17.14/iokit/Kernel/
IORegistryEntry.cpp:2005
#4 0x002ba9e4 in IORegistryIterator::getNextObjectRecursive
(this=0x1cf4e00) at /SourceCache/xnu/xnu-792.17.14/iokit/Kernel/
IORegistryEntry.cpp:2119
#5 0x002c1ffc in IOService::getExistingServices (matching=0x1da7b00,
inState=4, options=0) at /SourceCache/xnu/xnu-792.17.14/iokit/Kernel/
IOService.cpp:3177
#6 0x002c20cc in IOService::getMatchingServices (matching=0x1da7b00)
at /SourceCache/xnu/xnu-792.17.14/iokit/Kernel/IOService.cpp:3203
#7 0x002e9d00 in is_io_service_get_matching_services
(master_port=0xe3ed58, matching=0xe3ed58 "\001?G\002",
existing=0x1756bde0) at /SourceCache/xnu/xnu-792.17.14/iokit/Kernel/
IOUserClient.cpp:1276
#8 0x0008abdc in _Xio_service_get_matching_services
(InHeadP=0x20eff50, OutHeadP=0x21c7ea4) at device/device_server.c:945
#9 0x0002921c in ipc_kobject_server (request=0x20eff00) at /
SourceCache/xnu/xnu-792.17.14/osfmk/kern/ipc_kobject.c:309
#10 0x000233f8 in mach_msg_overwrite_trap (args=0xe3ed58) at /
SourceCache/xnu/xnu-792.17.14/osfmk/ipc/mach_msg.c:1597
#11 0x000abcac in .L_kernel_syscall_trapcall ()
#12 0x00000000 in lowGlo ()
-----------
(gdb) showcurrentstacks
task vm_map ipc_space #acts pid proc command
0x01a77968 0x00ce012c 0x01a6e760 1 53 0x01c79790 update
activation thread pri state wait_queue wait_event
0x01a84700 0x01a84700 51 R
kernel_stack=0x17568000
stacktop=0x1756bad0
0x1756bad0 0x0 <lowGlo>
0x1756bb40 0x2bc34 <kalloc_canblock+212>
0x1756bba0 0x2b15a8 <IOMalloc+24>
0x1756bbf0 0x2ba618
<_ZN18IORegistryIterator10enterEntryEPK15IORegistryPlane+36>
0x1756bc40 0x2ba9e4
<_ZN18IORegistryIterator22getNextObjectRecursiveEv+160>
0x1756bc90 0x2c1ffc
<_ZN9IOService19getExistingServicesEP12OSDictionarymm+444>
0x1756bd00 0x2c20cc
<_ZN9IOService19getMatchingServicesEP12OSDictionary+48>
0x1756bd50 0x2e9d00
<is_io_service_get_matching_services+92>
0x1756bda0 0x8abdc
<_Xio_service_get_matching_services+236>
0x1756be10 0x2921c <ipc_kobject_server+324>
0x1756be60 0x233f8 <mach_msg_overwrite_trap+3032>
0x1756bf30 0xabcac <.L_mach_return>
0x1756bfc0 0x0 <lowGlo>
stackbottom=0x1756bfc0
task vm_map ipc_space #acts pid proc command
0x01a79dd8 0x00ce0f3c 0x01a6eef0 41 0 0x003fc200 kernel_task
activation thread pri state wait_queue wait_event
0x01bb6f00 0x01bb6f00 0 IR
reserved_stack=0x17310000
kernel_stack=0x17358000
stacktop=0x11a3fe30
0x11a3fe30 0x0 <lowGlo>
0x11a3fe80 0x51ed20 <com.apple.driver.AppleMPIC +
0x1d20>
0x11a3fee0 0x2e2e90
<_ZN24IOCPUInterruptController15handleInterruptEPvP9IOServicei+72>
0x11a3ff20 0xada30 <interrupt+424>
0x11a3ff80 0xabf48 <ihandler_ret>
0x1735be30 0x33eb8 <idle_thread+48>
0x1735be90 0xa9514 <Call_continuation+20>
stackbottom=0x1735be90
-----------------------------
Any help with this is greatly appreciated, even if it's just to point
me in the right direction. Some of you may remember me sending
similar emails a while ago... after taking a break from this project
for several months I finally have time to work on it again, and
hopefully this time I will fix all these issues.
- Greg
On Jun 21, 2007, at 8:14 PM, Rob McKeever wrote:
Greg,
Download the appropriate kernel debug kit from <http://
developer.apple.com/sdk/>. Inside this disk image, you'll find
some instructions and a copy of both kgmacros and a kernel image
with debug symbols. Launch GDB on your remote machine against this
debug kernel and then you should be able to load the kgmacros just
fine.
-Rob
_______________________________________________
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