Re: Lion panic debugging
Re: Lion panic debugging
- Subject: Re: Lion panic debugging
- From: Brian Bechtel <email@hidden>
- Date: Wed, 27 Jul 2011 12:55:07 -0700
On Wed, Jul 27, 2011 at 12:23 PM, Kevin Brock <email@hidden> wrote:
> On Jul 27, 2011, at 11:48 AM, Shantonu Sen wrote:
>
> There's not an address in the backtrace which resolves to anything at all.
>
> Please be more specific. Addresses in kexts wouldn't be in the static kernel
> text, obviously.
>
> Obviously.
> I'm not talking about kext addresses not resolving. Â There are always frames
> in the backtrace which correspond to OS X panic handling code, or to the OS
> functions that called the kext, or to the call that actually crashed. Â The
> crash occurred on 11A511, and in the BT below, with the 11A511
> KernelDebugKit, none of the addresses as shown in the BT resolves to a known
> symbol.
I believe you aren't specifying "-arch i386" on your gdb command line.
When I do so, it works for me. Downloading the
kernel_debug_kit_10.7_11a511.dmg and mounting it, you get
/Volumes/KernelDebugKit. I then did the following:
$ gdb -arch i386 /Volumes/KernelDebugKit/mach_kernel
GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul 1 10:50:06 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...
(gdb) source /Volumes/KernelDebugKit/kgmacros
Loading Kernel GDB Macros package. Type "help kgm" for more info.
(gdb) x/i 0x22032e
0x22032e <panic+510>: mov 0x85fab4,êx
(gdb) x/i 0x24480e
0x24480e <zalloc_canblock+1198>: mov íi,%esi
(gdb) x/i 0x245069
0x245069 <zalloc+25>: add $0x8,%esp
(gdb) x/i 0x27e164
0x27e164 <_vm_map_entry_create+30>: mov êx,ëx
(gdb) x/i 0x23837c
0x23837c <task_create_internal+60>: jmp 0x2383c9 <task_create_internal+137>
(gdb) x/i 0x5645bf
0x5645bf <fork_create_child+47>: test êx,êx
(gdb) x/i 0x5646e9
0x5646e9 <cloneproc+73>: test êx,êx
(gdb) x/i 0x564b06
0x564b06 <fork1+662>: test êx,êx
(gdb) x/i 0x564c4d
0x564c4d <fork+45>: test êx,êx
(gdb) x/i 0x5f015a
0x5f015a <unix_syscall64+554>: cmpl $0x0,0x114(%esi)
(gdb) x/i 0x2e3977
0x2e3977 <lo64_unix_scall+23>: mov %esi,%esp
(gdb)
However, in panics such as these, the panic message "zalloc:
\"non-kernel map entries\" tells you that something is over allocating
memory. The non-kernel map entries zone was the zone where the
overallocation was first noticed, but it almost never is the zone
where the overallocation is happening. Later in the panic log, you'll
have a list of zones with more than 1 million allocations, and a
backtrace of the suggested leaking code (a new feature in Lion.) That
backtrace should be examined, rather than the backtrace of the panic.
In this kind of panic, the panic backtrace just gives you information
about the code path which noticed that we ran out of allocation space,
rather than the code which causes the leak.
Good luck.
_______________________________________________
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