Re: What software to debugging and analyzing C?
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?
This is a big deal especially debugging code that fails with -O3 but
succeeds
otherwise.
My approach (shamelessly stolen from GSL) is to write a debug callable
and let your debugger perform the "printf", rather than your own code.
$ cat oopsie.c
/* define an extern iff debugging */
#ifdef DEBUG
void oopsie(char *s,...){ }
#endif
And in your main code:
...
/* define an extern iff debugging */
#ifdef DEBUG
void oopsie(char *s,...);
#else
void oopsie(char *s,...){ }
#endif
int main(){
int i, j;
printf("%s\n","this is main.c demonstrating debug printing");
i = rand();
if(i> 5) oopsie("i more than 5");
...
Compile with DEBUG on. Run your code with the debugger, and break on
oopsie.
$ gdb ./main
...
(gdb) break oopsie
(gdb) run
Starting program: /home/jal/debug/a.out
...
this is main.c demonstrating debug printing
...
Breakpoint 1, oopsie (s=0x9766035d548 "i more than 5") at oopsie.c:4
4 void oopsie(char *s,...){ }
Backtrace tells you where oopsie was called.
J
Re: What software to debugging and analyzing C?
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 [...] Yes, I guess. > > 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? No, this did not occurred to me, at least not in such explicit way. Albeit somewhere deep I realise that program execution can change, if for example two "not related" lines of code switch places etc. (because of optimisation, for example). Before you pointed it out above I considered printf to be almost non-intrusive way of debugging. Thanks! -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_r...@bigfoot.com **
Re: What software to debugging and analyzing C?
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
Re: What software to debugging and analyzing C?
On Tue May 14 11:40:42 2024 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, I got used to doing this too. I started doing it intuitively, I'm self-taught (and I'm certainly not an expert).
Re: What software to debugging and analyzing C?
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?
Re: What software to debugging and analyzing C?
On Mon, May 13, 2024 at 08:24:38AM +0200, Janne Johansson wrote: > pkg_add llvm and run "scan-build" on your code, then you get a quite > thorough analysis on what potential error code paths it detects, with > fancy webpages to go along with the explanations for each found issue: > > http://c66.it.su.se:8080/obsd/scan-build-2019-10-10-202112-79522-1/report-3f2f00.html#EndPath > > It's not 100% perfect of course, but it still is a neat way to point > out where in the code you may need to make an extra effort to cover > corner cases. > > > I also wouldn't mind any other useful tips that might not be software. > > Any help very appreciated. > > Perhaps this fuzzing guide helps a bit getting programs to run better? > https://undeadly.org/cgi?action=article=20150121093259 Thank you and to the others replying. -- Regards, Chris Bennett "Who controls the past controls the future. Who controls the present controls the past." George Orwell - 1984
Re: What software to debugging and analyzing C?
> I found a YouTube channel LowLevelLearning that covers various > programming languages in a manner that I find particularly helpful and > clear. For example comparing C and assembly on the same code is superb. > > In a short, he recommended valgrind to help finding memory leaks. > Other than splint and gdb, what other software is useful for working > with C? pkg_add llvm and run "scan-build" on your code, then you get a quite thorough analysis on what potential error code paths it detects, with fancy webpages to go along with the explanations for each found issue: http://c66.it.su.se:8080/obsd/scan-build-2019-10-10-202112-79522-1/report-3f2f00.html#EndPath It's not 100% perfect of course, but it still is a neat way to point out where in the code you may need to make an extra effort to cover corner cases. > I also wouldn't mind any other useful tips that might not be software. > Any help very appreciated. Perhaps this fuzzing guide helps a bit getting programs to run better? https://undeadly.org/cgi?action=article=20150121093259 -- May the most significant bit of your life be positive.
Re: What software to debugging and analyzing C?
On Sun, May 12, 2024 at 11:51:32AM -0700, Chris Bennett wrote: > I found a YouTube channel LowLevelLearning that covers various > programming languages in a manner that I find particularly helpful and > clear. For example comparing C and assembly on the same code is superb. > > In a short, he recommended valgrind to help finding memory leaks. > Other than splint and gdb, what other software is useful for working > with C? > I also wouldn't mind any other useful tips that might not be software. > Any help very appreciated. 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. This approach does not look sexy enough to show it on y-t, so I guess there will not be a movie showing it. Besides, all debuggers introduce their own perturbation and thus certain classes of error will be very hard to catch with them, if ever. It also sometimes happened to me, that debugger pointed to wrong place, where the error supposedly happened. Very wrong place - like GUI code when in fact the bug was in database communication. I think it all becomes even more funky if you start playing with multithreaded apps and languages which come with threads built-in, under the hood. All of those things happened many years ago - perhaps debuggers improved, I have no idea. So, I suggest that you do: man tee and after that: ./yourcode 2>&1 | tee log.txt and: less log.txt -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_r...@bigfoot.com **
Re: What software to debugging and analyzing C?
On May 12 11:51:32, cpb_m...@bennettconstruction.us wrote: > In a short, he recommended valgrind to help finding memory leaks. man malloc
Re: What software to debugging and analyzing C?
Otto Moerbeek thought me this: First compile your program with debug symbols (and, conveniently, without optimization settings.) $ DEBUG="-g -O0" make Then: $ MALLOC_OPTIONS=D ktrace -tu $ kdump -u malloc kdump will though you lines like this: 0x34f10a4b153 20480 1 20480 addr2line -e /usr/lib/libc.so.97.1 0x4d153 0x34f10a96470 410576 25 16423 addr2line -e /usr/src/usr.bin/ 0x98470 If you compiled your program with debugging symbols and your program has some leak, the name of your program will appear in some of those lines. Then you run that addr2line command and it'll show you in which file and line the leak is produced. It will show your errors that valgrind won't.
What software to debugging and analyzing C?
I found a YouTube channel LowLevelLearning that covers various programming languages in a manner that I find particularly helpful and clear. For example comparing C and assembly on the same code is superb. In a short, he recommended valgrind to help finding memory leaks. Other than splint and gdb, what other software is useful for working with C? I also wouldn't mind any other useful tips that might not be software. Any help very appreciated. -- Regards, Chris Bennett "Who controls the past controls the future. Who controls the present controls the past." George Orwell - 1984
