Re: generic type, tree

On May 18, 4:54 pm, j...@xxxxxxxxxxx (Jens Thoms Toerring) wrote:
Eligiusz Narutowicz <eligiuszdotn...@xxxxxxxxxxx> wrote:
Antoninus Twink <nos...@xxxxxxxxxxxxxx> writes:
On 18 May 2008 at 10:46, Jens Thoms Toerring wrote:
alternative...@xxxxxxxxx wrote:
int v = 1;
node *n = malloc(sizeof(node));
n->value = &v;

Here you have a bad problem. What you store in the 'value' member
is a pointer to a variable that vanishes the moment you return
from this function.

You're right, but perhaps it will also be helpful to mention to the OP
that tracking down such bugs is very easy using the valgrind tool, which
will pick up invalid memory accesses like this. (This is just in case
the OP isn't a preternaturally talented programmer like all the clc
regulars, who as we know have no need for debugging tools besides their
eyes.)
If the OP is using Linux (or Windows too I think) then splint is also
quite good. I got the link from this group I think.

While splint indeed gives you some hint at what's going wrong
(alas in a way that probably will make it hard for the OP to
grasp) using valgrind seems to me like looking for your mis-
placed keys with a microscope. All it tells you is something
about an invalid read in the affiche() function, rather likely
just reinforcing the OP in the wrong belive that there would
be something wrong with this function and not helping at all
in finding the real reason for the problem. I would recommend
to use valgrind (or similar memory debuggers) only as a last
resort and instead to learn to avoid such mistakes since val-
grind can only detect the results of those mistakes, not the
mistakes themselves.

While I don't often agree with Mr. Twink, but I think that (assuming
the OP is using Linux, of which I can see absolutely no hint in his
post) using valgrind early and often is a good thing. Even on
programs that seem to work. I added it to our large regression suite
a while back at work and found a number of defects that way that had
not been otherwise noticed. They were of the class of things (e.g.
off by one errors causing invalid memory reads/writes) that can cause
difficult to diagnose at the customer site memory corruptions, but
often aren't detected in unit testing... I'm thus a big fan of using
valgrind (and in the past purify) at any stage of development...

I also agree with your point to some degree, that being able to find
these things by eye is a good thing. A competent code inspector
should be able to catch return of automatic memory (or putting it into
a struct that is returned).

-David
.

Relevant Pages

  • Re: generic type, tree
    ... grasp) using valgrind seems to me like looking for your mis- ... resort and instead to learn to avoid such mistakes since val- ... a while back at work and found a number of defects that way that had ... off by one errors causing invalid memory reads/writes) that can cause ...
    (comp.lang.c)
  • Re: purge like utility in c
    ... As you well know valgrind can be used with any standard C program where as garbage collection cannot. ... Apart from that, on x86 and amd64, essentially all instructions are supported, up to and including SSE2. ... This will affect any use of synchronization via memory shared between processes. ... For each exception, two courses of action are defined by 754: either a user-defined exception handler may be called, or a default action is defined, which "fixes things up" and allows the computation to proceed without throwing an exception. ...
    (comp.lang.c)
  • [TOOL] Valgrind, an Open-Source Memory Debugger for x86-GNU/Linux
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... reads and writes of memory are checked, ... As a result, Valgrind can detect ... Valgrind contains built-in support for doing very detailed cache ...
    (Securiteam)
  • Re: Program crashes - debugging suggestions?
    ... > program that crashes about every 10-12 hours. ... > soon as the memory being overwritten is in use by another thread. ... Valgrind is a GPL'd system for debugging and profiling x86-Linux ...
    (comp.os.linux.development.apps)
  • Re: Program crashes - debugging suggestions?
    ... > program that crashes about every 10-12 hours. ... > soon as the memory being overwritten is in use by another thread. ... Valgrind is a GPL'd system for debugging and profiling x86-Linux ...
    (comp.os.linux.embedded)