From owner-freebsd-current@FreeBSD.ORG Thu May 2 09:27:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E5D299CE; Thu, 2 May 2013 09:27:40 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [204.107.128.56]) by mx1.freebsd.org (Postfix) with ESMTP id C366D107E; Thu, 2 May 2013 09:27:40 +0000 (UTC) Received: from [10.0.1.12] (host31-51-203-234.range31-51.btcentralplus.com [31.51.203.234]) by cyrus.watson.org (Postfix) with ESMTPSA id CDF1D46B5E; Thu, 2 May 2013 05:27:39 -0400 (EDT) Subject: Re: panic: in_pcblookup_local (?) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <20130502005704.GB1623@glenbarber.us> Date: Thu, 2 May 2013 10:27:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130501180321.GA44525@glenbarber.us> <49916D2B-496A-40EA-971F-62951FF6B584@freebsd.org> <201305011430.37106.jhb@freebsd.org> <20130502005704.GB1623@glenbarber.us> To: Glen Barber X-Mailer: Apple Mail (2.1283) Cc: Ian FREISLICH , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 09:27:41 -0000 On 2 May 2013, at 01:57, Glen Barber wrote: > So, I am admittedly not too familiar with DDB. In fact, I just now > realize the kernel is built without DDB... DDB is a very powerful tool in that it's been custom-developed to help = debug common kernel panics. It lacks some of the flexibility, and = especially the data-type awareness of GDB, but GDB is a less well-suited = tool when investigating common crash patterns. I'll usually start out = debugging in DDB, and find that 90% of my in-development panics can be = debugged with it, resorting to GDB for post-mortem analyses in = production or particularly hard debugging cases (usually where DDB's = pretty printers for data types fall short). I've wanted, for a long = time, to teach DDB how to pretty-print arbitrary types using DTrace's = CTF meta-data, which would address the most significant major case where = I turn to GDB. Mind you, the limitations I see in GDB are made up for in = most part by John's GDB scripts :-). >> Put those in a dir and do 'source gdb6'. You can then run 'ps' to = get a good=20 >> ps listing that includes threads. You can also use 'thread apply all = bt' to=20 >> get stacktraces of all threads in kgdb. I believe there is an = 'allpcpu'=20 >> command that is similar to 'show allpcpu' in DDB. >=20 > I have the outputs of 'ps', 'allpcpu', and 'thread apply all bt' saved > to separate script(1) files. Is there anything in particular I can = look > for before uploading the files somewhere public? At quick-ish look > though, I did not see anything cf-agent (the current process at time = of > panic) related. To be honest, it's probably easiest if I just take a look at it and see = what I see. In as much as I find interesting things, I'll follow up = explaining what they are. We may find we can't track this problem down = from the data we have -- but it's worth a try. Robert=