[flac-dev] [PATCH] Add missing functions to VorbisComment class + a few other things

Bastiaan Timmer basjetimmer at yahoo.com
Tue May 8 08:13:01 PDT 2012


--- On Tue, 5/8/12, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote:

> Honestly, I really doubt this is a bug in valgrind :-). How
> were you testing
> this?

Well, I've read that there have been bugs in valgrind, were SSE optimized versions of strlen() do guaranteed safe overreads of memory, but valgrind wasn't aware the overreads were safe.

Anyway, it seems easy to reproduce for me, but I still may just be doing something stupid:

[~]$ cat main.cc
#include <FLAC++/metadata.h>

int main()
{  
  FLAC::Metadata::VorbisComment::Entry entry("ARTIST", "Someone cool and terribly hip");
  return 0;
}
[~]$ g++ -Wall -Wextra -O1 -g -lFLAC++ -o invalid_read main.cc 
[~]$ valgrind ./invalid_read 
==11150== Memcheck, a memory error detector
==11150== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==11150== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==11150== Command: ./invalid_read
==11150== 
==11150== Invalid read of size 4
==11150==    at 0x4030366: FLAC::Metadata::VorbisComment::Entry::set_field_name(char const*) (metadata.cpp:653)
==11150==    by 0x7D5E35: (below main) (in /lib/libc-2.13.so)
==11150==  Address 0x418802c is 4 bytes inside a block of size 7 alloc'd
==11150==    at 0x4007D89: malloc (vg_replace_malloc.c:236)
==11150==    by 0x83502F: strdup (in /lib/libc-2.13.so)
==11150==    by 0x4030347: FLAC::Metadata::VorbisComment::Entry::set_field_name(char const*) (metadata.cpp:649)
==11150==    by 0x7D5E35: (below main) (in /lib/libc-2.13.so)
==11150== 
==11150== 
==11150== HEAP SUMMARY:
==11150==     in use at exit: 0 bytes in 0 blocks
==11150==   total heap usage: 5 allocs, 5 frees, 119 bytes allocated
==11150== 
==11150== All heap blocks were freed -- no leaks are possible
==11150== 
==11150== For counts of detected and suppressed errors, rerun with: -v
==11150== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 21 from 8)
[~]$ 

Note, this is linked to current git (installed to /usr/local):
[~]$ ldd invalid_read | grep -i flac
        libFLAC++.so.5 => /usr/local/lib/libFLAC++.so.5 (0x00358000)
        libFLAC.so.8 => /usr/local/lib/libFLAC.so.8 (0x00110000)
[~]$

The exact same program, linked to the distro's current stable release (1.2.1):
[~]$ g++ -Wall -Wextra -O1 -g -L/usr/lib -lFLAC++ -I/usr/include/ -o ok_read -Xlinker -rpath -Xlinker /usr/lib main.cc 
[~]$ ldd ok_read | grep -i flac
        libFLAC++.so.6 => /usr/lib/libFLAC++.so.6 (0x00f89000)
        libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0x061d0000)
[~]$ valgrind ./ok_read 
==11241== Memcheck, a memory error detector
==11241== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==11241== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==11241== Command: ./ok_read
==11241== 
==11241== 
==11241== HEAP SUMMARY:
==11241==     in use at exit: 0 bytes in 0 blocks
==11241==   total heap usage: 5 allocs, 5 frees, 119 bytes allocated
==11241== 
==11241== All heap blocks were freed -- no leaks are possible
==11241== 
==11241== For counts of detected and suppressed errors, rerun with: -v
==11241== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 21 from 8)
[~]$

I still have this creeping suspicion I'm missing something obvious...

Thanks for looking at and applying my patches the last few days by the way!

Bas


More information about the flac-dev mailing list