From owner-freebsd-arch@FreeBSD.ORG Sat Feb 9 09:38:21 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 868FE6B5; Sat, 9 Feb 2013 09:38:21 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 34641BC; Sat, 9 Feb 2013 09:38:20 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so2859736vba.27 for ; Sat, 09 Feb 2013 01:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6VPB4hPPXSL5f19Ss1OFop55MRuiFsNYlyzoGJV+GOg=; b=1IQGGKGORRGI7y3HpOTVZsTssK4QVf46Pr6ASs2Z0vI1C+TdqSYGGWGf+r/elS53IL fiNRyiAnxH6F5TjTrml++HmtgiN2nxFfGUamGm8Dk3DScr3Z2LdM32UHJg1c6gF20Hp2 wMiMdrOWUzA+/53WtJ6+4Rj9Taaqzz3H7QqCMs+KOiVPHlgMv/TYVjGfd6lKozOzIbSF n2I185rMfZxppf147fejdHDHB8/Mmn2jJAQ/w1gzgmAW4DE0Aupmh55yJLTDMK96vUTD 6gTOU69bDGnflLFDjGLqlwzDJrQv9drl2X4k/q93plPcROBGKOpgPZKx5gzJ93UrCG7M z1lQ== MIME-Version: 1.0 X-Received: by 10.52.24.114 with SMTP id t18mr8968622vdf.62.1360402700231; Sat, 09 Feb 2013 01:38:20 -0800 (PST) Received: by 10.58.170.36 with HTTP; Sat, 9 Feb 2013 01:38:20 -0800 (PST) In-Reply-To: <5116121E.1010601@FreeBSD.org> References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <5116121E.1010601@FreeBSD.org> Date: Sat, 9 Feb 2013 01:38:20 -0800 Message-ID: Subject: Re: Proposal: Unify printing the function name in panic messages() From: Mehmet Erol Sanliturk To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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 09:38:21 -0000 On Sat, Feb 9, 2013 at 1:08 AM, 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. > > > 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. > > -- > Andriy Gapon > During 1980 years we were using a Burroughs 6700 main frame . Its Fortran compiler produced code was generating a call stack trace on run time errors . That facility was very useful during finding possible causes . That main frame was using ONLY TWO MEGA BYTES of main memory . Now I am using such a facility with G95 Fortran compiler by setting a compiler switch : It is giving a call stack listing with line numbers of calls when a run time error occurs with line number of error point . A similar structure may be used for FreeBSD parts generated during compilation when a compiler switch is set . Making such a setting as default may be more useful because it is unknown when a run time error occurs . By submitting such call stack lists to developers will make their problem solution tasks much more easier than the currently required much more conversations to identify the cause and call steps . Therefore , this is mainly a compilation problem which can be achieved with current structure of sources . Thank you very much . Mehmet Erol Sanliturk