From owner-freebsd-arch@FreeBSD.ORG Sat Feb 9 22:51:38 2013 Return-Path: Delivered-To: freebsd-arch@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 E8A8E2AC; Sat, 9 Feb 2013 22:51:38 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id E2947C26; Sat, 9 Feb 2013 22:51:19 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r19MpDlt036260; Sat, 9 Feb 2013 15:51:13 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r19HFXrB037385; Sat, 9 Feb 2013 10:15:33 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Proposal: Unify printing the function name in panic messages() From: Ian Lepore To: Andriy Gapon In-Reply-To: <5116121E.1010601@FreeBSD.org> References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <5116121E.1010601@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Sat, 09 Feb 2013 10:15:33 -0700 Message-ID: <1360430133.4545.68.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Kirk McKusick , Christoph Mallon , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 22:51:39 -0000 On Sat, 2013-02-09 at 11:08 +0200, Andriy Gapon wrote: > on 09/02/2013 10:51 Christoph Mallon said the following: > > On 07.02.2013 23:12, Andriy Gapon wrote: > >> on 07/02/2013 23:35 Christoph Mallon said the following: > >>> panic("just a message"); > >> > >> This seems perfect. > >> Panic without at least a stack trace or preferably a crash dump is practically > >> useless in most cases. A stack trace already has all the function names. > >> So a function name in a message seems to be redundant. > > > > This is nice in theory, but infeasible in practice. > > More than half of the panic() calls include the correct function name in a way or another. > > I estimate, that another quarter show a wrong name. > > In any case, you just search the code for the message and that's it. > I don't suppose that there are many duplicates there. > Exactly. The use of sufficiently descriptive messages is all that's necessary for finding the source of a panic or other error. It has taken me over 30 years to come around to this way of thinking, but during the past 5 years of working in a shop with a large source base and no file/line numbers in the logging, I've seen the light. What I've found to be the far bigger modern problem is not finding the source of a given message in the code, but rather finding out WHO said it, given the growing ubiquity of multi-threaded code. -- Ian > > It is hard to get this number mechanically, because, well, the names are wrong. > > So most calls include the name (or try to). > > Having no function name is a minority. > > I plan to correct and unify this hotchpotch. > > Also, if stack traces are disabled, you at least can reliably determine, where the panic came from. > > Even if you can determine that, without more debugging data that would be > useless in most cases. (We paniced because something went wrong, but why did it > happen?) > > > Finally, you can turn the names on and off with one central switch. > > Well, have you experienced any problems with debugging due to those > (absent/misleading) function names? Or do you see many reports about such problems? > > If this is a solution in search of a problem, then I don't like it, because it > requires massive, if mostly mechanical, changes throughout the code. > > If panic message like ("invalid value of bar") were to be changed to something > like ("invalid value of bar (%foo)", bar) I would find that to be a far more > useful project. >