site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oCc94szWAvmiy+cgbj/gkHCW+6Quf0f2MFNhmG6KT9M=; b=CXHwDhJZ7oFB2xFOFAaPTQ7zTugyFp4ApunFUCnrLjT7Zm0L1pnuxbLrNMQDurUZ4Z ehSnYhQDJmn6itsLtzTv0MSODx4QuvjJdEkUl3+465YG44z8krwrdC3t1imQWqyhWYCB DkICEIyLIfhS+Me92YWwnY0rQqovPLjfMOso0= On Wed, Jul 27, 2011 at 12:23 PM, Kevin Brock <apple@kevin.com> 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,%eax (gdb) x/i 0x24480e 0x24480e <zalloc_canblock+1198>: mov %edi,%esi (gdb) x/i 0x245069 0x245069 <zalloc+25>: add $0x8,%esp (gdb) x/i 0x27e164 0x27e164 <_vm_map_entry_create+30>: mov %eax,%ebx (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 %eax,%eax (gdb) x/i 0x5646e9 0x5646e9 <cloneproc+73>: test %eax,%eax (gdb) x/i 0x564b06 0x564b06 <fork1+662>: test %eax,%eax (gdb) x/i 0x564c4d 0x564c4d <fork+45>: test %eax,%eax (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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com