On Tue, 6 Nov 2007 07:14:51 -0500
"matthew sporleder" <msporleder@gmail.com> wrote:

> On Nov 6, 2007 7:10 AM, Antti Kantee <pooka@cs.hut.fi> wrote:
> > On Tue Nov 06 2007 at 07:03:34 -0500, matthew sporleder wrote:
> > > > Actually, I believe in the "no debug options at all" approach,
> > > > i.e. all debugging code enabled all the time, but that's
> > > > another bikeshed.
> > > >
> > >
> > >
> > > Isn't the ideal situation to have these options available at
> > > runtime, then less desirable would be to toggle them at boot, and
> > > then least desirable is in the kernel config itself?
> >
> > Ignoring the technical aspects: No, that doesn't solve the problem:
> > "whoops, had a crash, better toggle my debugging options on now...
> > oh... bummer" ;)
> >
> > And when you do turn them on your problem of course magically
> > doesn't happen anymore.
> >
> 
> It's better than "whoops I had a crash, now I need a new kernel."  :)
> (maybe enabling at boot is the best idea-- yay bootprops)
> 
> I can't really speak to the debugging solving issues because I've
> never seen it happen myself.
> 
I have, as recently as last month and as long ago as 40 years.
Sometimes, there are race conditions and the debug printouts change the
timing; other times, the debug code changes the storage layout.

Me -- I like C.A.R. Hoare's warning from his Turing Award lecture:

	The first principle was security: ...  A consequence of
	this principle is that every occurrence of every subscript
	of every subscripted variable was on every occasion checked
	at run time against both the upper and the lower declared
	bounds of the array.  ... I note with fear and horror that
	even in 1980, language designers and users have not learned
	this lesson. In any respectable branch of engineering,
	failure to observe such elementary precautions would have
	long been against the law.

I think it generalizes to many more debugging options being on all the
time.


		--Steve Bellovin, http://www.cs.columbia.edu/~smb