Date: Sun, 23 Jan 2011 15:04:22 -0800 From: Garrett Cooper <gcooper@FreeBSD.org> To: David Demelier <demelier.david@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: why panic(9) ? Message-ID: <AANLkTimd6X_P8Mykvnmp_kEWJoi5siNarVU5M3xFtG28@mail.gmail.com> In-Reply-To: <4D3CB2FE.2080603@gmail.com> References: <AANLkTi=OQbS-0jJx0YwZhM7xDWPLOkaYYZAYfESUEvvM@mail.gmail.com> <AANLkTi=6ODRNH5Z_oRVzqWStAuv%2B4-aBDoUSY5baYkvQ@mail.gmail.com> <4D3CB2FE.2080603@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 23, 2011 at 3:00 PM, David Demelier
<demelier.david@gmail.com> wrote:
> On 12/01/2011 00:03, Garrett Cooper wrote:
>>
>> On Tue, Jan 11, 2011 at 12:11 PM, David DEMELIER
>> <demelier.david@gmail.com> =A0wrote:
>>>
>>> Hello,
>>>
>>> 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.
>>>
>>> Yes, why this function exists? There is no way to solve a problem
>>> without panic'ing? 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() !
>>>
>>> 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.
>>>
>>> I'm guessing now, if minix panic when a bloated crappy software is
>>> running. I think Andrew is in the right way.
>>
>> =A0 =A0 So I guess with that reasoning we don't need asserts, bugs never
>> occur, and the if the computer catches on fire we should just let it
>> burn up instead of getting an extinguisher and put it out :D?
>> =A0 =A0 As an example: I would rather have my PC panic and not write out
>> corrupt data to disk instead of write out that corrupt data to disk.
>> The latter has happened with userland apps on occasion before they
>> crash, and that really fries my bacon... Similarly, if we're beyond
>> recovery, panicing is the best and only option, but yes... recovery
>> could be handled better in some cases. Filesystems are a bit trickier
>> though because they're more mission critical than say a non-critical
>> device driver (my sound driver?) tanking.
>
> In any case, when panic occurs, switching display to the tty can be great=
.
> Why not a sysctl like kern.tty_on_panic? Because when you're running X an=
d a
> panic occurs not everybody understand what happens.
>
> Or the problem for me, when a panic occurs it *NEVER* core dump. Absolute=
ly
> never, it stops at a moment but does not finish so I need to be in tty to
> debug directly so that's why a tty switch may helps in my case :-)
That request makes sense...
Thanks,
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimd6X_P8Mykvnmp_kEWJoi5siNarVU5M3xFtG28>