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 23:53:23 -0400
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.
- Greg
_______________________________________________
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