Messages in this thread | | | Date | Tue, 12 Sep 2000 01:57:40 +0200 | From | almesber@lrc ... | Subject | Debugger (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/
| |