Skip Menu |

This queue is for tickets about the Test-Valgrind CPAN distribution.

Report information
The Basics
Id: 44836
Status: stalled
Priority: 0/
Queue: Test-Valgrind

People
Owner: Nobody in particular
Requestors: frequency [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.08
Fixed in: (no value)



Subject: Spurious Errors (Supposed to be supressed?)
Hi: Thanks for releasing such a useful module! Running a test script with Test::Valgrind on an XS module, I get output like this: t/02valgrind........# ==15779== Memcheck, a memory error detector. # ==15779== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. # ==15779== Using LibVEX rev 1884, a library for dynamic binary translation. # ==15779== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. # ==15779== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation framework. # ==15779== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. # ==15779== For more details, rerun with: -v # ==15779== # ==15779== Conditional jump or move depends on uninitialised value(s) # ==15779== at 0x808A3F3: Perl_re_compile (in /usr/bin/perl) # ==15779== by 0x80F09B1: Perl_pp_regcomp (in /usr/bin/perl) # ==15779== by 0x80B1878: Perl_runops_standard (in /usr/bin/perl) # ==15779== by 0x80ABD07: Perl_call_sv (in /usr/bin/perl) # ==15779== by 0x80AC0EE: Perl_call_list (in /usr/bin/perl) # ==15779== by 0x8064C9E: (within /usr/bin/perl) # ==15779== by 0x8072B27: Perl_newATTRSUB (in /usr/bin/perl) # ==15779== by 0x8071A1F: Perl_utilize (in /usr/bin/perl) # ==15779== by 0x815ED67: Perl_yyparse (in /usr/bin/perl) # ==15779== by 0x80AE8BD: (within /usr/bin/perl) # ==15779== by 0x80AF874: perl_parse (in /usr/bin/perl) # ==15779== by 0x8063DA0: main (in /usr/bin/perl) # No tests run! # ==15779== # ==15779== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 48 from 4) # ==15779== malloc/free: in use at exit: 84 bytes in 2 blocks. # ==15779== malloc/free: 50,064 allocs, 50,062 frees, 2,383,217 bytes allocated. # ==15779== For counts of detected errors, rerun with: -v # ==15779== Use --track-origins=yes to see where uninitialised values come from # ==15779== searching for pointers to 2 not-freed blocks. # ==15779== checked 243,624 bytes. # ==15779== # ==15779== LEAK SUMMARY: # ==15779== definitely lost: 0 bytes in 0 blocks. # ==15779== possibly lost: 0 bytes in 0 blocks. # ==15779== still reachable: 0 bytes in 0 blocks. # ==15779== suppressed: 84 bytes in 2 blocks. t/02valgrind........1/2 # valgrind /usr/bin/valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=12 --error-limit=yes --log-fd=8 --suppressions=/usr/lib/perl5/Test/Valgrind/perlTestValgrind.supp /usr/bin/perl -I/home/jon/cpan/tests/Math-Random-ISAAC-XS/blib/lib -I/home/jon/cpan/tests/Math-Random-ISAAC-XS/blib/arch -I/etc/perl -I/usr/local/lib/perl/5.10.0 -I/usr/local/share/perl/5.10.0 -I/usr/lib/perl5 -I/usr/share/perl5 -I/usr/lib/perl/5.10 -I/usr/share/perl/5.10 -I/usr/local/lib/site_perl -I. -MTest::Valgrind=run,1 t/02valgrind.t I'm not sure how to interpret it. Is it a real error? The reason I'm filing a bug report is because the diagnostic output says "supressed: 84 bytes in 2 blocks" - and that's the only error. So shouldn't the test pass? I'm running Debian squeeze. Here's my perl -V output: Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Platform: osname=linux, osvers=2.6.26-1-686, archname=i486-linux-gnu-thread-multi uname='linux rebekka 2.6.26-1-686 #1 smp mon dec 15 18:15:07 utc 2008 i686 gnulinux ' config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.10.0 -Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.10.0 -Dd_dosuid -des' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2 -g', cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='4.3.2', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /usr/lib64 libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt perllibs=-ldl -lm -lpthread -lc -lcrypt libc=/lib/libc-2.7.so, so=so, useshrplib=true, libperl=libperl.so.5.10.0 gnulibc_version='2.7' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under linux Compiled at Jan 1 2009 12:22:18 @INC: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl Thanks in advance, and thanks again for your module! I apologize if this is just a mistake in me understanding the diagnostic output. There is a chance that this is an actual memory leak, in which case there's nothing you can do about it :-) Cheers, Jonathan
Show quoted text
> Hi: > > Thanks for releasing such a useful module! >
Hello, Thank you for showing interest in Test::Valgrind. Show quoted text
> > I'm not sure how to interpret it. Is it a real error? The reason I'm > filing a bug report is because the diagnostic output says "supressed: 84 > bytes in 2 blocks" - and that's the only error. So shouldn't the test
pass? Valgrind reports that all the leaks were suppressed but this memory misread error wasn't. It happened inside perl (understand : not in your module) and as such it should have been suppressed. So it's a bug in this sense. However, the suppression generation is still a little flaky, because it's difficult to isolate the Perl snippet that would generate a given error with a given perl on a given machine. Your best bet is just to ignore it. I'm currently rewriting the internals of the module so that it'll be easier to hack on it (as in e.g. regenerating suppressions on the user end). No timescale implied though. Vincent. NB: In your t/02valgrind.t test, I've seen that you define a plan before calling Test::Valgrind->import. This is bad, because Test::Builder can't plan twice so it'll have to use your plan of 2 tests - and Test::Valgrind actually requires 5. So either remove your plan, or plan after importing. I should have made this explicit in the doc though.