Re: Kernel panic help - kernel controls?
Re: Kernel panic help - kernel controls?
- Subject: Re: Kernel panic help - kernel controls?
- From: Greg <email@hidden>
- Date: Fri, 22 Jun 2007 01:49:17 -0400
Clarification: "callback function for sending data" refers to the
callback function that is called when the client sends the KEXT data.
On Jun 22, 2007, at 1:46 AM, Greg wrote:
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:
40kinostudios.com
This email sent to email@hidden
_______________________________________________
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