Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > valgrind spews avalanche of messages

Reply
Thread Tools

valgrind spews avalanche of messages

 
 
Öö Tiib
Guest
Posts: n/a
 
      06-30-2013
On Sunday, 30 June 2013 12:53:41 UTC+3, Ike Naar wrote:
> On 2013-06-29, ?? Tiib <(E-Mail Removed)> wrote:
> > On Saturday, 29 June 2013 16:30:26 UTC+3, (E-Mail Removed) wrote:
> >> I built an open-source package that comprises hundreds of source files
> >> in C, C++, F90 among others. It has a few bugs suggesting memory
> >> corruption, such as SIGSEGV or malloc and free aborts.

> >
> > Open source is often of rather terrible quality. Not as rule, just often.

>
> Same for closed source.
> At least with open source one can see how bad things are.


It is not benefit. When someone asks me to look into source code of
closed source then they usually offer money for that. With open
source ... maybe others are better at that ... but I have got noteworthy
money for working on open source only once.
 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      06-30-2013
On Sat, 2013-06-29, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> I built an open-source package that comprises hundreds of source files
> in C, C++, F90 among others. It has a few bugs suggesting memory
> corruption, such as SIGSEGV or malloc and free aborts.
>
> So I tried valgrind --tool=memcheck
> It throws up hundreds of warnings about


These may well be your fault, as the others say.

But note that valgrind comes with "suppressions" -- warnings from
popular libraries (like the Gnu libc) which have been investigated and
found harmless. If you're working on an exotic combination of OS,
compiler and libc you may not have the best possible set of
suppressions.

The valgrind documentation can tell you more.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      07-01-2013
James Kuyper <(E-Mail Removed)> wrote:
> On 06/30/2013 05:11 AM, Malcolm McLean wrote:


(snip)
>> I'm guessing (it's only a guess) that intel_fast_memcmp takes
>> arbitrary unsigned char *s and lengths, aligns them on 64 bit
>> boundaries, and if all 64 bit chunks match, returns 0. If the
>> edge bits don't match, it does AND and OR masking to get the
>> correct answer.


>> So valgrind will think it's using uninitialised memory,
>> which it is, but legitimately. (Not legal in C, but it's
>> not written in C).


Or maybe written in non-standard C. While one can't portably
write things like that, within an implementation one can either
write the assembler code for it, or write it using the C compiler.
(Note that I didn't say write it in C.)

> I'll concede that's a possibility, but it seems far more
> plausible to me that calling code is defective by reason of
> calling _intel_fast_memcmp() (directly or indirectly) to
> compare two buffers, one or both of which has uninitialized
> memory within the specified length. Developers often make mistakes
> like that, which is one of the main reasons for the very
> existence of tools like valgrind.


If the implementation is doing that, then a version of valgrind for
that implementation should know about it.

-- glen
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      07-01-2013
On 07/01/2013 03:24 PM, glen herrmannsfeldt wrote:
> James Kuyper <(E-Mail Removed)> wrote:

....
>> I'll concede that's a possibility, but it seems far more
>> plausible to me that calling code is defective by reason of
>> calling _intel_fast_memcmp() (directly or indirectly) to
>> compare two buffers, one or both of which has uninitialized
>> memory within the specified length. Developers often make mistakes
>> like that, which is one of the main reasons for the very
>> existence of tools like valgrind.

>
> If the implementation is doing that, then a version of valgrind for
> that implementation should know about it.


I was referring to a defect in the user code, not a defect in the
implementation.


 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      07-01-2013
On Sat, 29 Jun 2013 22:23:31 -0500, Gordon Burditt wrote:

> It *is* possible that a highly-optimized C library reads beyond the end of
> a string, say, 8 bytes at a time, yet still operates correctly because the
> compiler knows that its malloc() implementation won't ever allocate the
> last 7 bytes of a virtual memory chunk, so the code won't segfault by
> going beyond the end of the string, but valgrind doesn't know this.


It doesn't matter whether malloc() allocates the last few bytes of a page.

A string-processing algorithm which works in e.g. 8-byte units will
invariably work in *aligned* 8-byte units, so it will only read bytes
beyond the end of a string when those bytes are within the same alignment
unit as one or more bytes of the string, and thus within the same page.

 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      07-02-2013
On 01-Jul-13 14:55, Nobody wrote:
> On Sat, 29 Jun 2013 22:23:31 -0500, Gordon Burditt wrote:
>> It *is* possible that a highly-optimized C library reads beyond the
>> end of a string, say, 8 bytes at a time, yet still operates
>> correctly because the compiler knows that its malloc()
>> implementation won't ever allocate the last 7 bytes of a virtual
>> memory chunk, so the code won't segfault by going beyond the end of
>> the string, but valgrind doesn't know this.

>
> It doesn't matter whether malloc() allocates the last few bytes of a
> page.
>
> A string-processing algorithm which works in e.g. 8-byte units will
> invariably work in *aligned* 8-byte units, so it will only read
> bytes beyond the end of a string when those bytes are within the same
> alignment unit as one or more bytes of the string, and thus within
> the same page.


malloc() implementations often allocate smallish blocks in a set of
fixed sizes, typically multiples of 8, to reduce heap fragmentation.
Since the start of each block needs to be aligned for any data type,
also typically 8 bytes, that means that reading from such blocks in
aligned chunks of 8 bytes will be safe from segfaults. As long as an
optimized memcmp() or strcmp() doesn't actually _use_ data from beyond
the proper length, it's not an error--at least for code, eg. Intel's
optimized libraries, that can be reasonably considered part of the
implementation.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Psycho "Taylor Jimenez" is psycho Joe Jared, psychopath & SPEWS creator Nomen Nescio Computer Support 0 08-29-2006 05:40 PM
Man peed way out of avalanche Pennywise@DerryMaine.gov Computer Support 3 01-28-2005 10:09 PM
Re: SPEWS (Spam Prevention Early Warning System) under attack? Stuart NZ Computing 3 09-05-2003 01:59 AM
Re: SPEWS (Spam Prevention Early Warning System) under attack? Nigel Howe NZ Computing 9 09-04-2003 09:17 PM
concentric.net falsely listed by SPEWS Frog Computer Support 2 08-29-2003 10:32 AM



Advertisments