site_archiver@lists.apple.com Delivered-To: Darwin-kernel@lists.apple.com Here is what I have set up: -------------------- ----------- ----------------------------- - Greg On Jun 21, 2007, at 8:14 PM, Rob McKeever wrote: Greg, _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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". 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. 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 This email sent to site_archiver@lists.apple.com