lkml.org 
[lkml]   [2000]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectDebugger (was Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linu)
Kai Henningsen wrote:
> A classical memory corruption bug, and like most late-effect bugs hell to
> find without some sort of support for poking around in the actual program
> state.

Agreed. My usual debugging procedure is as follows:

1. try to reproduce the problem
2. make an educated guess what may be wrong and look in the code to
see if that's what's happening
3. repeat 2. a few times
4. sprinkle the suspected location and surrounding functions with
printk("[a]"); printk("[b]"); etc. to see where exactly it dies
(ksymoops is pretty useless if your system is dead after the bug,
and I don't want to maintain the infrastructure for a serial
console (if feasible at all))
5. based on the findings, try 2. again
6. add more printks to show the contents of all interesting variables
7. based on the findings, try 2. again
8. check assembler code
9. try to work around the bug ;-)

Steps 4. and 6. taint the source tree, so there's a certain risk that
I break something and/or debugging changes end up in the patch with
the fix. Sometimes, the changes are big enough that, after finding a
satisfying fix, I need to start over with a fresh tree. Again, this
adds the risk of missing some changes.

I'm quite used to this procedure by now, but a "standard" kernel
debugger would certainly improve steps 4. and 6. It might also help
with the rather annoying problems of a long sequence of Oops following
the first one, or the Oops output getting too long.

Also, I don't think the absence of a debugger is sufficient protection
against placebo or voodoo "fixes", or vice versa.

- Werner

--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.318 / U:0.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site