On 1/1/2015 3:16 PM, "João M. S. Silva" wrote:
> The problem is in:
>
> char command[128];
> sprintf(command, "first part of command %s second part of command",
> filename.c_str());
>
> The string is larger than 128 bytes. But valgrind does not detect this?
> Am I missing something?
>
> I forgot to mention, I'm using valgrind from SVN in an ARM machine.
>
> I usually use the version from SVN since it has a lot of false positives
> corrected.
>
> The log file shows 0 errors but a lot of:
>
> ==2346== Warning: invalid file descriptor 29541 in syscall read()
>
> which make it difficult to interpret the results.
>
> Should I report a bug and a suggestion upon this SVN version?
>
>
If the command buffer is a global variable, then no. valgrind looks for
memory errors in allocated memory, not static memory. Even if the
command buffer is an automatic variable (i.e. inside a function), it can
be hard for valgrind to see out-of-bounds problems.
The basic idea is that valgrind allocates a little bit of memory before
and after the block you want, then looks for writes into those boundary
areas. If your memory write is way out of bounds for one block, it
could land in another allocated block. valgrind has no way of knowing
whether this is correct or not because it is working at the assembly
language level.
Tom Hughes' suggestion to fix the invalid file descriptor first is
valid. A memory overwrite can cause all kinds of problems (what if you
overwrote 1 million characters of the buffer?) and many of the results
afterward will be unreliable. Your program may appear to run correctly
once, but it is a disaster waiting to happen.
The procedure for cleaning up a program is to fix all of the problems
you know how to fix, then rerun valgrind. Repeat until all errors are
gone. Errors late in a program's run may have been caused by earlier
errors. New errors may appear after you fix the initial set of
problems; they were simply masked by the previous errors.
You are on the right track; you need to keep at it. There have been
times when I've had so many problems in so many places that I simply
fixed the first one and reran valgrind. In your case, the "bad file
descriptor" error was a symptom of another problem, not a cause. Once
you fix that you can move on to any other problems that may appear.
As you have seen, debugging is an art. It takes time to learn to do it
well, even with valgrind's valuable assistance. We've all been there
and we're happy to help.
You could file a valgrind enhancement request but personally I wouldn't
bother. There were many bad uses of the file descriptor; valgrind
simply reported them all. I agree with Tom - this is a case where I
would fix that one error and start over. Repetition detection can be
tricky and the valgrind developers may have other priorities.
--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
