Re: Kernel panic help - kernel controls?
Re: Kernel panic help - kernel controls?
- Subject: Re: Kernel panic help - kernel controls?
- From: Greg <email@hidden>
- Date: Sat, 23 Jun 2007 17:31:21 -0400
I was able to fix the panic, the culprit turned out to be some code I
was using (seemingly from a trustworthy and reputable source) that
recycled memory allocations (to prevent unnecessary mallocing).
Forgive me for the misguided accusations at kernel controls, it's
just that I did not trust my understanding of them and the backtraces
from gdb were fairly vague.
I then came across another panic that was caused by what I *think*
are boundary alignment problems in a data structure that I have, I've
implemented a simple hack-like fix for it but I'm sure there has to
be a better way.
#define MAXLEN 64
struct ItemStruct {
int len;
int flags;
char inQueue;
#if ALIGNMENT_HACK
char *name;
#else
char name[MAXLEN];
#endif
char *other;
};
The panic occurs when I try to free it like so:
kern_os_free(item->other);
kern_os_free(item);
It will not panic if I do not free item->other.
The temporary solution that I've implemented is to simply malloc()
name as well and do:
kern_os_free(item->name);
kern_os_free(item->other);
kern_os_free(item);
I tried to stick __attribute__((aligned(4))) and __attribute__
((packed)) in various places but I'm not very experienced at using
those and all the combinations I could think of still resulted in
kernel panics.
Anyone know why this is happening?
- Greg
On Jun 22, 2007, at 11:53 PM, Greg wrote:
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:
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