From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 21:07:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CC67106566C for ; Tue, 11 Jan 2011 21:07:52 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id EF8918FC12 for ; Tue, 11 Jan 2011 21:07:51 +0000 (UTC) Received: (qmail 46128 invoked from network); 11 Jan 2011 20:41:09 -0000 Received: from unknown (HELO ?10.0.0.179?) (spawk@128.238.64.31) by acm.poly.edu with CAMELLIA256-SHA encrypted SMTP; 11 Jan 2011 20:41:09 -0000 Message-ID: <4D2CC06A.8080408@acm.poly.edu> Date: Tue, 11 Jan 2011 15:41:14 -0500 From: Boris Kochergin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101106 Thunderbird/3.1.6 MIME-Version: 1.0 To: David DEMELIER References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: why panic(9) ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Tue, 11 Jan 2011 21:07:52 -0000 On 01/11/11 15:11, David DEMELIER wrote: > Hello, > Hi. > I'm just guessing why current BSD panic() when a problem occurs, all > modern operating systems solve the problem instead of crashing > suddently and corrupting all your data without saving your work. All modern operating systems? Maybe some niche ones, like the ones that run on Mars rovers, have made progress towards formal verification and are believed not to crash given correctly-functioning hardware. The latest versions of Windows, OS X, and Linux all panic. > Yes, why this function exists? There is no way to solve a problem > without panic'ing? Imagine you've got a machine with bad RAM. It corrupts a pointer in the kernel filesystem code. Imagine there is some code in the kernel filesystem code that checks whether a pointer points to memory belonging to the kernel filesystem code before dereferencing it, and the check failed. What should happen? Continued execution will, at best, lead to flamboyant failure of kernel subsystems or userspace programs, and, at worst, will silently destroy or modify data in memory or on your disk. (By the way, this actually happens.) > Is panic really needed? Imagine someone working on > something really important and his computer just panic, his work not > saved everybody shout at him in the corporation. He lose his job, his > wife, his dog, everything is wrong, just because of a panic() ! When I do kernel work, I keep my source code on an NFS share on a known-stable machine so that when the machine I'm working on inevitably crashes, I don't lose my code. Reliability is about more than software choices. There are other best practices to consider. > Seriously, I really hate when I play some music that suddenly the > music get stucked in a infinite loop, why ? I don't know because the > panic does not core dump. But after some search I found that the panic > was done because of conky. How the hell conky can panic FreeBSD? We > are in 2011 ! I think even Window 2000 does not crash on a user-land > software. Frustrating at it may be, there are things you can do, like compiling your kernel with DDB and performing online debugging. -Boris > I'm guessing now, if minix panic when a bloated crappy software is > running. I think Andrew is in the right way.