site_archiver@lists.apple.com Delivered-To: Darwin-kernel@lists.apple.com - 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... Sorry for the followup email, but this one is a bit more concise and I've been able to narrow the problem down a bit. I'm able to reproduce the kernel panic by connecting and reconnecting the daemon to the KEXT. Again, it establishes two connection on startup to the KEXT via kernel controls. To simplify things right now only the daemon is sending the KEXT information, the KEXT does not send anything back. The system seems stable on the initial connect, but if I quit the daemon and relaunch it, and repeat this several times, eventually the system (10.4.9 PPC), will panic. There does not seem to be any specific pattern as to what will actually set off the panic, it might happen after I move the mouse, or click on something while the daemon is connected. The most common backtrace that I get is this: 0x002fc368 in OSArray::flushCollection (this=0x1d99c80) at / SourceCache/xnu/xnu-792.17.14/libkern/c++/OSArray.cpp:216 216 /SourceCache/xnu/xnu-792.17.14/libkern/c++/OSArray.cpp: No such file or directory. in /SourceCache/xnu/xnu-792.17.14/libkern/c++/OSArray.cpp Current language: auto; currently c++ (gdb) bt #0 0x002fc368 in OSArray::flushCollection (this=0x1d99c80) at / SourceCache/xnu/xnu-792.17.14/libkern/c++/OSArray.cpp:216 #1 0x002fc1ec in OSArray::free (this=0x1d99c80) at /SourceCache/xnu/ xnu-792.17.14/libkern/c++/OSArray.cpp:160 #2 0x00303bfc in OSSet::free (this=0x1e6c1e0) at /SourceCache/xnu/ xnu-792.17.14/libkern/c++/OSSet.cpp:154 #3 0x002d96f8 in IOMemoryDescriptor::free (this=0x2329800) at / SourceCache/xnu/xnu-792.17.14/iokit/Kernel/IOMemoryDescriptor.cpp:2628 #4 0x002dcf88 in IOBufferMemoryDescriptor::free (this=0x2329800) at / SourceCache/xnu/xnu-792.17.14/iokit/Kernel/ IOBufferMemoryDescriptor.cpp:361 #5 0x007cbcc0 in log_level () #6 0x007bf6cc in log_level () #7 0x002ec0cc in is_io_connect_method_scalarI_structureI (connect=0x1c425c40, index=32522880, input=0x21c6cc4, inputCount=36319744, inputStruct=0x21c6ccc "", inputStructCount=0) at /SourceCache/xnu/xnu-792.17.14/iokit/Kernel/IOUserClient.cpp:2394 #8 0x0008c744 in _Xio_connect_method_scalarI_structureI (InHeadP=0x21c6c9c, OutHeadP=0x226eda8) at device/device_server.c:5128 #9 0x0002921c in ipc_kobject_server (request=0x21c6c00) at / SourceCache/xnu/xnu-792.17.14/osfmk/kern/ipc_kobject.c:309 #10 0x000233f8 in mach_msg_overwrite_trap (args=0x1c425c40) at / SourceCache/xnu/xnu-792.17.14/osfmk/ipc/mach_msg.c:1597 #11 0x000abcac in .L_kernel_syscall_trapcall () #12 0x494f4469 in ?? () Cannot access memory at address 0xbfffd070 Cannot access memory at address 0xbfffd078 What could cause this? The KEXT itself is very simple and written in C. It has the two functions (_start(), _stop()) to be loaded and unloaded from the kernel. Although it does use the IOCreateThread function, it is not a C++ IOKit kernel extension. Again, any help with this is greatly appreciated, I've been banging my head over this problem the past several days and have been unable to make much progress. This email sent to site_archiver@lists.apple.com