02 Oct, 2012, arholly wrote in the 1st comment:
Votes: 0
Hi:
I was wondering if anyone had any advice for new coders on tracking down memory leaks? I know to use Valgrind, which is great for telling me it exists, but I don't really know how to approach it from there or how to do it.

Arholly
02 Oct, 2012, Barrons wrote in the 2nd comment:
Votes: 0
I would give you more advice, but I'm short on time. Try: http://www.yolinux.com/TUTORIALS/C++Memo...

There is some pretty good information there, and it is incidentally the #1 return on Google for the terms "memory leak tutorial" :D
05 Oct, 2012, Tyche wrote in the 3rd comment:
Votes: 0
That's a pretty decent tutorial. I'd recommend becoming familiar with your C code and using your debugger to examine the stack, the global storage area and heap.
Everything you need to find the error can be found in the abend dump of your program. Really.
Like I said before, Valgrind is pretty much useless for debugging.

I wrote an example of debugging a stack corruption a few years back: HowToFindStackBugs
I also host a tutorial written by a TMC poster, Genghis: SegmentationFault
YMMV
06 Oct, 2012, Rarva.Riendf wrote in the 4th comment:
Votes: 0
Quote
Like I said before, Valgrind is pretty much useless for debugging.

Because Valgrind is not a tool for debugging, it is a tool to find bugs…
Gdb is the debug tool, once you know where are your bugs found by Valgrind….

btw you may want to edit your example, it does not sig on my config
http://sourcery.dyndns.org/wiki.cgi?HowT...

last Fedora 64 bit in a virtualbox image.

Guess they did put some safe check in sprintf (in gdb buf was limited to 10 char)

edit:weird, under gdb it crashes with a sig, under normal run it just stop without saying why (under eclipse…)
06 Oct, 2012, Lyanic wrote in the 5th comment:
Votes: 0
Rarva.Riendf said:
Quote
Like I said before, Valgrind is pretty much useless for debugging.

Because Valgrind is not a tool for debugging, it is a tool to find bugs…
Gdb is the debug tool, once you know where are your bugs found by Valgrind….


debug? ?[dee-buhg]
verb (used with object), debugged, debugging. Informal.
1. to detect and remove defects or errors from.

So you're saying Valgrind is only half a debugger? I'm confused.
06 Oct, 2012, Rarva.Riendf wrote in the 6th comment:
Votes: 0
Valgrind will not remove a bug, as you cannot interact with the code while running it, with GDB you can.

"Official Home Page for valgrind, a suite of tools for debugging and profiling"
Valgrind is not a debugging tool by itself,
06 Oct, 2012, quixadhal wrote in the 7th comment:
Votes: 0
Rarva is right. A chisel isn't a tool for cutting stone. It won't actually cut the stone without a hammer to strike it. A screwdriver isn't a tool to tighten or loosen screws, because it won't do so without someone's hand to turn it.
06 Oct, 2012, Rarva.Riendf wrote in the 8th comment:
Votes: 0
Yeah a chisel is pretty much useless to cut a stone if you dont have a hammer. That is the point. It is half of the tool needed to cute a stone, as Valgrind is half the tool needed to debug. While with gdb you do not need any other tool to debug. You can use sarcam as much as you want. You just proved my point.
07 Oct, 2012, Davion wrote in the 9th comment:
Votes: 0
Rarva.Riendf said:
Valgrind will not remove a bug, as you cannot interact with the code while running it, with GDB you can.


Ok, that's not entirely true. If you run valgrind with –vgdb you can get a sort of gdb-like behaviour (with external tools of course).

If I were to give you advice on tracking a memory leak, I'd first ask if you actually have a memory leak. Proven examples of your memory footprint expanding abnormally during normal operation of program. Then, and only then should you go to valgrind. The reverse is pedantic and often yields little fruit.
07 Oct, 2012, Runter wrote in the 10th comment:
Votes: 0
In my opinion the value in valgrind is using it as a profiler. It helps you find optimization opportunity where you could look at it through gdb all day and never catch the same thing. It's two separate tools with separate purpose. Gdb is pretty standard for when you know what the problem behavior is. Valgrind is going to save you a lot of time one memory related stuff, though, compared to gdb.
07 Oct, 2012, Rarva.Riendf wrote in the 11th comment:
Votes: 0
Quote
then, and only then should you go to valgrind. The reverse is pedantic and often yields little fruit.

Valgrind is not only there to catch memory leak but also buffer overuns that can stay hidden under the radar for a very long time.
It is not pedantic to run valgrind while running all the test unit you can. There is a reason all the big open source project use it. It saves a lot of time finding bugs that are not always triggered.
There is absolutely no reason to not run it when you code in C when you have the occasion, provided your computer can handle it.

And good luck finding a memory leak when it is only 1 byte per byte and only a method that is called from time to time at random…just by looking at memory footprint…
Have a test unit call that method, run valgrind, there you go you know you have a leak. Waiting a long time to fix a bug can make it harder to debug as well.
07 Oct, 2012, Tyche wrote in the 12th comment:
Votes: 0
Rarva.Riendf said:
btw you may want to edit your example, it does not sig on my config

It's a wiki that anyone can edit. Feel free to update it or create a better example. You might consider unwinding your stack to discover why you didn't get a segmentation fault and where your program continued to execute. Stack corruption doesn't necessarily lead one to execute code outside the bounds of one's program. Stacks aren't really a part of C; but they are a very common implementation especially on x86 architectures. It's important to understand the specific conventions one's implementation are operating under in order to debug C programs on that platform. It means that just knowing C (or Fortran, Pascal or whatever) is not enough to know how to debug.

Rarva.Riendf said:
Guess they did put some safe check in sprintf (in gdb buf was limited to 10 char)

It's simply not possible to put in a safety check for the first parameter.
int sprintf(char *str, const char *format, …);
Try it. sprintf() doesn't operate under any different conditions than user written functions.
It's why other functions like snprintf() are often recommended.

Rarva.Riendf said:
There is a reason all the big open source project use it.

This is false, as well as your statement on an earlier thread.
Rarva.Riendf said:
Then you must be the god of programmation, every big project out there use it to find the very common bug in C like memory leaks or buffer overun.

It should be obvious that a tool that up until a year or two ago only ran on Linux is not used by every nor all big projects, nor even a majority of those developed on Linux. BTW, Google returns 800 million plus hits for "Linux", 5 million hits for "LPMud" and only 1 million for "Valgrind". I've worked on big (complex) projects, and one of the common features of many such projects is the need for custom memory management. That often rules out using Valgrind and many other leak detectors on such projects. Those who don't use memory leak detectors aren't gods, just experienced and competent. Debugging like any other programming skill is something that can be easily learned by anyone who can learn a language, although it's not the same skill… that is an architecture can be thought of as an additional language one need learn. However, just like anything it requires time, effort and desire. Most people just want to build and run a mud game. Unfortunately, that interest doesn't necessarily intersect with the effort, time and desire to learn programming. And more unfortunately one's choice of server often dictates the need to know C programming/debugging. Too bad.

I'm sure that Valgrind and their ilk may be useful for some projects as a QA tool, but as someone implied learning to use Valgrind is backwards.
Learn C. Learn your architecture. Then you can debug.

Debugging a gdb dump is far more interactive than simply showing and reading posted C code. So it's harder to do via email or over forums.
But there are patterns to it and tutorials do capture some of them and the techniques used to solve them.
07 Oct, 2012, Rarva.Riendf wrote in the 13th comment:
Votes: 0
Quote
This is false, as well as your statement on an earlier thread.

http://valgrind.org/gallery/users.html yeah right this is false…guess all those programmers are incompetent and unexperienced…

Quote
It should be obvious that a tool that up until a year or two ago only ran on Linux is not used by every nor all big projects, nor even a majority of those developed on Linux.

My bad for saying Valgrind instead of a tool of its kind, as there are other tools that do the same function on other platforms. Like Purify.

Quote
I've worked on big (complex) projects, and one of the common features of many such projects is the need for custom memory management.

Yeah and…Valgrind does more than just checking for memory leaks. And does not care about how you allocae your memory anyway.

Quote
Those who don't use memory leak detectors aren't gods, just experienced and competent.

And foolish to think they will never make any mistakes.

Quote
Learn C. Learn your architecture. Then you can debug.

And use modern tools to save time instead of waiting for your program to crash with a corrupted stack when a program can detect it for you….
09 Oct, 2012, Tyche wrote in the 14th comment:
Votes: 0
Rarva.Riendf said:
http://valgrind.org/gallery/users.html yeah right this is false…

No that's true. There are a handful of Linux projects using ValGrind, even a few high profile ones.

Rarva.Riendf said:
Quote
I've worked on big (complex) projects, and one of the common features of many such projects is the need for custom memory management.

Yeah and…Valgrind does more than just checking for memory leaks. And does not care about how you allocae your memory anyway.

That's exactly why it's not useful for many projects. And that includes several mud projects.

Rarva.Riendf said:
Quote
Those who don't use memory leak detectors aren't gods, just experienced and competent.

And foolish to think they will never make any mistakes.

By definition, they already know that.

Rarva.Riendf said:
Quote
Learn C. Learn your architecture. Then you can debug.

And use modern tools to save time instead of waiting for your program to crash with a corrupted stack when a program can detect it for you….

What did Valgrind tell you about the buffer overrun and stack corruption in my example?
Did it save you any time?
09 Oct, 2012, Rarva.Riendf wrote in the 15th comment:
Votes: 0
Quote
What did Valgrind tell you about the buffer overrun and stack corruption in my example?

You have one example that sig right away on the line the bug is created, basically the simplest bug to solve…it is totally unrelevant. Now have a buffer overrun somewhere in your code that triggers a crash once in a while at random, and tell me how gdb can help…oh wait, it will not since the stack is corrupted anyway.

Quote
There are a handful of Linux projects using ValGrind, even a few high profile ones.

Euphemism to say: mostly all of the high profile one that are written in C do…

Quote
That's exactly why it's not useful for many projects. And that includes several mud projects.

Yeah right buffer overruns/read write out of bonds never happen as soon as you use custom memery allocation..oh wait…shrug
10 Oct, 2012, Runter wrote in the 16th comment:
Votes: 0
Rarva.Riendf said:
Quote
That's exactly why it's not useful for many projects. And that includes several mud projects.

Yeah right buffer overruns/read write out of bonds never happen as soon as you use custom memery allocation..oh wait…shrug


Unfortunately, for most custom memory allocation systems valgrind will not help catch buffer overruns or read out of bounds since it's often all part of continuous memory that was allocated with a single call to malloc.

I think the take away is that for some projects it may be of use and for others it won't be.
10 Oct, 2012, Rarva.Riendf wrote in the 17th comment:
Votes: 0
Valgrind does not only catch only memory leaks or even memory out of bounds, it also catch things like loop ofset (often leading to read/write memory at the wrong place, again, those probably wont trigger any visible bugs). Again whatever your memory system allocation is, Valgrind has an use, not using a tool of this kind before releasing code in C is simply unprofessional.
10 Oct, 2012, Barrons wrote in the 18th comment:
Votes: 0
quixadhal said:
Rarva is right. A chisel isn't a tool for cutting stone. It won't actually cut the stone without a hammer to strike it. A screwdriver isn't a tool to tighten or loosen screws, because it won't do so without someone's hand to turn it.
I see what you did thar.. :D
11 Oct, 2012, Tyche wrote in the 19th comment:
Votes: 0
Rarva.Riendf said:
Quote
What did Valgrind tell you about the buffer overrun and stack corruption in my example?

You have one example that sig right away on the line the bug is created, basically the simplest bug to solve…it is totally unrelevant. Now have a buffer overrun somewhere in your code that triggers a crash once in a while at random, and tell me how gdb can help…oh wait, it will not since the stack is corrupted anyway.


Valgrind does not handle buffer overruns on either global or stack allocated arrays. Neither does it handle stack corruption either.

A reasonably intelligent person should be able to extrapolate from the example that they might receive something like the following when their mud server crashes:
Program received signal SIGSEGV, Segmentation fault.
0x696b7570 in ?? ()
(gdb) bt
#0 0x696b7570 in ?? ()
#1 0x7320676e in ?? ()
#2 0x796e6968 in ?? ()
#3 0x61777320 in ?? ()
#4 0x6f206472 in ?? ()
#5 0x75756420 in ?? ()
#6 0x00002e6d in ?? ()
#7 0x0022acf8 in ?? ()
Cannot access memory at address 0x20676966

If you think finding the bug in my 6 lines of C code was simple.
Now tell me which of the 50000 lines of C in the above mud server is causing the problem?
Duh

But this!??
Rarva.Riendf said:
…and tell me how gdb can help…oh wait, it will not since the stack is corrupted anyway.

Breathtaking stupidity.

Rarva.Riendf said:
… not using a tool of this kind before releasing code in C is simply unprofessional.

LOL

For the OP…
Here's another good tutorial on the same subject: Is your stacktrace really corrupted?
11 Oct, 2012, Ssolvarain wrote in the 20th comment:
Votes: 0
Just a completely off-topic observation:
I love watching people argue with Tyche.
0.0/20