Re: What software to debugging and analyzing C?

2024-05-16 Thread j



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?

2024-05-14 Thread Tomasz Rola
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?

2024-05-14 Thread Chris Bennett
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?

2024-05-14 Thread Walter Alejandro Iglesias
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?

2024-05-14 Thread Crystal Kolipe
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?

2024-05-13 Thread Chris Bennett
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&sid=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?

2024-05-12 Thread Janne Johansson
> 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&sid=20150121093259


-- 
May the most significant bit of your life be positive.



Re: What software to debugging and analyzing C?

2024-05-12 Thread Tomasz Rola
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?

2024-05-12 Thread Jan Stary
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?

2024-05-12 Thread Walter Alejandro Iglesias
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?

2024-05-12 Thread Chris Bennett
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