[Daca-general] How did cppcheck catch a dma memleak? :)

[Peter Pentchev]

Hi,

First of all, *many* thanks for thinking of and implementing DACA!
George Danchev had been talking to me about cppcheck off and on over
many beers these past couple of years, but I never really got 'round
to checking it out - and it seems to be very useful, for at least two
of my packages so far :)

Now, here's the question.  What version of cppcheck is run to produce
the reports at http://qa.debian.org/daca/cppcheck/ and, if it is 1.44-1
as available in both unstable and testing right now, is there something
special about its environment that would make it catch the memory leak
at http://qa.debian.org/daca/cppcheck/sid/dma_0.0.2010.06.17-6.html ? :)

The thing is, I've checked out the daca scripts from the Alioth repo,
and from what I can see in scripts/local/run-cppcheck.sh, it seems to
run "cppcheck -v --xml ." and parse its output.  However, from
a freshly apt-get source'd copy of dma_0.0.2010.06.17-6, if I run:

  cppcheck -v --xml . 2>../dma.2 > ../dma.1

...I get the following XML in dma.2:

<?xml version="1.0"?>
<results>
</results>

...and I get this progress output in dma.1:

Checking ./base64.c...
1/12 files checked 8% done
Checking ./conf.c...
2/12 files checked 16% done
Checking ./crypto.c...
3/12 files checked 25% done
Checking ./debian/migrate/dma-migrate.c...
Checking ./debian/migrate/dma-migrate.c: O_EXLOCK...
Checking ./debian/migrate/dma-migrate.c: __GNUC__...
Checking ./debian/migrate/dma-migrate.c: __printflike...
4/12 files checked 33% done
Checking ./dfcompat.c...
Checking ./dfcompat.c: NEED_GETPROGNAME...
Checking ./dfcompat.c: NEED_GETPROGNAME;__GLIBC__...
Checking ./dfcompat.c: NEED_REALLOCF...
Checking ./dfcompat.c: NEED_STRLCPY...
5/12 files checked 41% done
Checking ./dma.c...
Checking ./dma.c: HAVE_RANDOM...
Checking ./dma.c: HAVE_RANDOM;HAVE_SRANDOMDEV...
Checking ./dma.c: SA_NOCLDWAIT...
6/12 files checked 50% done
Checking ./dns.c...
Checking ./dns.c: TESTING...
7/12 files checked 58% done
Checking ./local.c...
Checking ./local.c: HAVE_LIBLOCKFILE...
8/12 files checked 66% done
Checking ./mail.c...
Checking ./mail.c: HAVE_RANDOM...
9/12 files checked 75% done
Checking ./net.c...
10/12 files checked 83% done
Checking ./spool.c...
11/12 files checked 91% done
Checking ./util.c...
Checking ./util.c: O_EXLOCK...
12/12 files checked 100% done

As you can see, not a word about a memory leak in crypto.c - but then
when I fire up an editor and look at the code around line 277, lo and
behold, there *is* indeed a memory leak, just as DACA reported on
the webpage :)

So, um, how do I reproduce this actual good catch with my version of
cppcheck? :)  cppcheck seems to be working pretty much fine here other
than this - just today it caught two errors and two weird things in
the dante package that I've since fixed.

Once again, thanks for all y'all are doing, and keep up the great work!

G'luck,
Peter

-- 
Peter Pentchev	roam at space.bg    roam at ringlet.net    roam at FreeBSD.org
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
Hey, out there - is it *you* reading me, or is it someone else?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/daca-general/attachments/20101224/0325645f/attachment.pgp>