On Tue, May 14, 2024 at 05:19:43AM -0300, Crystal Kolipe wrote: > On Sun, May 12, 2024 at 10:26:55PM +0200, Tomasz Rola wrote: > > I am sure gdb has some merits but for whatever C programs I wrote so > > far, a much more useful debugging technique was putting printf in > > right places and isolate the problem, and after that doing some mental > > work to actually understand why this seemingly correct line does > > something so wrong. > > Exactly. What you describe is likely the best method to fully understand the > code, what it's supposed to do and what it actually does, and by extension > avoid making the same coding mistakes in the future. Finding and fixing a > single error with gdb doesn't have the same educational benefit, nor in > many cases such a guarantee that other nearby bugs have also been noticed. > > > Besides, all debuggers introduce their own perturbation and thus > > certain classes of error will be very hard to catch with them, if > > ever. > > But you do realise that adding printf() calls to the code can also change, > for example, the memory layout that the compiler uses, so certain memory > allocation bugs might become more or less easily triggerable?
Yes, I do realize that printf has that flaw. I also program some in Perl. print, warn, die, etc. can sometimes help, but often they don't. Carefully studying or just trying to rewrite a section of code from scratch is the only solution. Many years ago I wrote a trivial Perl script wrong. It very slowly grabbed more and more memory until it crashed the server about every two days. After very carefully watching, I figured out it was my script and I fixed a rather silly bug. I'll never forget that experience. -- Regards, Chris Bennett "Who controls the past controls the future. Who controls the present controls the past." George Orwell - 1984
