Re: [Valgrind-users] suppress warning repetition

[David C. <dcc...@ac...>]

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      dcc...@ac...
     Chapman Consulting -- San Jose, CA
     Software Development Done Right.
     www.chapman-consulting-sj.com