valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Valgrind & Matlab

[Sami R. <sam...@un...>]

Hi,

I have a C++ program which requires the Matlab (www.mathworks.com)
libraries to work. This is the most usual c++ program, the only thing is
that it requires matlab libraries in order to read .mat files.

When I use valgrind on a (ripped off) version of my program which was
not linked with the matlab lib, it works. When linked with the matlab
libs it does not and the following error message appears when I run
valgrind on my program:

==6422== Memcheck, a.k.a. Valgrind, a memory error detector for
x86-linux.
==6422== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==6422== Using valgrind-1.9.6, a program instrumentation system for
x86-linux.
==6422== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==6422== Estimated CPU clock rate is 2787 MHz
==6422== For more details, rerun with: -v
==6422==
Table 1. block_array is currupt
mwmem.c:1010: Assert : Forced Assertion "Unaligned pointer found in
cache"
Aborted

I tried to look in the source code of valgrind for this mwmem.c file,
but couldn't find it. I'm then assuming that this files comes from the
matlab libraries (difficult to be sure as nm does not work on the matlab
.so libs)

So, is there any chance to use valgrind with programs linked with matlab
libraries or not ?

Sami.

-- 
http://informatik.unibas.ch/personen/romdhani_sami/

[Valgrind-users] Letter

[..... <aaa...@ne...>]

Dear friend

With regards and honor do please consider this proposal.I am from Zimbabwe but currently i and my brother is in Netherland.You might be worried how i got your contact address, I got it from Chamber of Commerce and trade e-mail directory.

Dear friend during this crises against the farmers of Zimbabwe by the supporters of our President Robert Mugabe to claim all the white owned farms in our country, he ordered all the white farmers to surrender their farms to his party members and their followers

My father was one of the best farmers in the country and knowing that he did not support the presidents political ideology, the presidents supporters invaded my fathers farm burnt down everything, shot him and as a result of the wounds sustained, he became sick and died after four days.And after his death,I and my younger Brother decided to move out of Zimbabwe for the safety of our lives to South-Africa.from thier we where able to enter into a 
ship and travel to the Netherland.

But, before he died he wrote his will, which reads (MY BELOVEED SON ,I WISH TO DRAW YOUR ATTENTION TO THE SUM OF ($7.5,000000). MILLION U.S DOLLARS WHICH I DEPOSITED IN A SECURITY COMPANY IN JOHANNESBURG (SOUTH-AFRICA)and i have ask them to transfer it to thier branch in the netherland and secured it.IN CASE OF MY ABSENCE ON EARTH CAUSED BY DEATH ONLY".You should solicit for reliable foreign partner to assist you to transfer this money out of netherland for investment purpose.

I deposited the money in your name and it can be claimed by you alone with the deposite code. your mother has all the documents.Take good care of your mother and brother."

From the above, you will understand that the lives and future of my family depends on this money as much, I will be grateful if you can assist us.I and my younger brother are now living in the Netherland as POLITICAL ASYLUM SEEKERS and the financial law of the Netherland does not allow ASYLUM SEEKERS certain financial rights to such huge amount of money .

In view of this, I cannot invest this money in the Netrherland,hence I am asking you to assist me transfer this money out of Netherland and secure it for investment purposes. 

For your efforts, I am prepared to offer you 10% of the total fund, while 2% will be set aside for local and international expenses and 88% will be kept for me and my family.

Finally modalities on how the transfer will be done will be conveyed to you once we establish trust and confidence between ourselves. Looking forward to hear from you For more detailed information. 

NOTE:THE KEY WORD TO THIS TRANSACTION IS ABSOLUTE CONFIDENTIALITY AND SECRECY.THIS TRANSACTION IS 100% RISK FREE. YOUR URGENT RESPONSE WILL BE HIGHLY APPRECIATED.

BEST REGARDS,

[Valgrind-users] New file descriptor leakage patch

[Robert W. <rj...@du...>]

Hi all,

Here's the latest version of the file descriptor leakage patch.  It
applies against the CVS head as of Sun May 18.

New in this version:

      * Catch some cases I missed before (creat() and F_DUPFD.)
      * Print out some useful information on leaking sockets.
      * Remove annoying "Attempting to close unopened file descriptor"
        messages.
      * Figure out inherited file descriptors even on machines that
        don't have /proc support compiled into the kernel.  I've never
        come across a machine without /proc support, but it is an
        optional kernel feature, so...
      * Other minor fixes and changes.

This will probably be the last release I make before I make some changes
suggested by Nicholas.  These changes will be to move it out of the core
and into memcheck and to enable it only if a command-line flag is set.

Regards,
 Robert.

-- 
Robert Walsh
Amalgamated Durables, Inc.  -  "We don't make the things you buy."
Email: rj...@du...

[Valgrind-users] Using Valgrind with Matlab?

[Maurits R. <lpe...@co...>]

Hi,

Is it possible to use Valgrind (and in particular Cachegrind) on Matlab 
mex files? And somewhat related: I would also like to use Valgrind on 
GIMP plug-ins. Anyone has experience with running Valgrind on plug-in 
like architectures?

Maurits

Re: [Valgrind-users] refcounters, cycles and leak detection.

[Nicholas N. <nj...@ca...>]

On Thu, 15 May 2003, Chris Sheppard wrote:

> Is there any way to make valgrind detect that there's a cycle?  IE we
> (like many others) have a reference counted smart pointer in our
> application library, which gets used all the time.  As you might guess,
> you have to be careful to avoid cycles, else you create things that,
> once you get rid of the external handle, their existing handles to one
> another will prevent their deletion.
>
> I created a very trivial test of this, and it didn't seem to detect that
> I had leaked the 2 objects (A had nothing but a handle to B, B had
> nothing but a handle to A).  I guess this is because there ARE valid
> references, but I'm just wondering if there's any way to get valgrind to
> detect this?

The leak detector works like this: at termination, it scans through all
addressible memory looking for anything that looks like a pointer.  For
any remaining heap blocks, if there are any pointers to the start (or the
middle) of the block found during the scan, the block is considered
reachable (or possible lost).  This is imperfect, because occasionally
you'll get a "fake" pointer to a lost block just from a coincidental junk
value, but it doesn't happen very often.

So that's why no leak was reported for your cycle -- the leak checker
found a pointer to each object, and considered them reachable.

Adding cycle checking would be possible -- ignore a pointer within heap
block A to heap block B if the only pointer to heap block A is within heap
block B -- but it would be difficult.  At a guess, I'd say more difficult
than is worth it.  I'd be happy for someone to prove me wrong, though.

N

[Valgrind-users] refcounters, cycles and leak detection.

[<sh...@ne...>]

Is there any way to make valgrind detect that there's a cycle?  IE we 
(like many others) have a reference counted smart pointer in our 
application library, which gets used all the time.  As you might guess, 
you have to be careful to avoid cycles, else you create things that, 
once you get rid of the external handle, their existing handles to one 
another will prevent their deletion. 

I created a very trivial test of this, and it didn't seem to detect that 
I had leaked the 2 objects (A had nothing but a handle to B, B had 
nothing but a handle to A).  I guess this is because there ARE valid 
references, but I'm just wondering if there's any way to get valgrind to 
detect this?

Chris

RE: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind

[Troels W. H. <tr...@th...>]

I just dicovered that RH has updated the glibc errata for RH8 to version
2.3.2-4.80.6.
https://rhn.redhat.com/errata/RHSA-2003-089.html

There is also a 2.3.2-27.9 version for RH9:
https://rhn.redhat.com/errata/RHBA-2003-136.html

The changelog for the RH8 package contains the entry below, and Valgrind
1.9.6 now works unpatched. The bugzilla entry for that change is at=20
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D86437

"* Sun Apr 06 2003 Jakub Jelinek <ja...@re...> 2.3.2-4.80.5
- make sure all calls to __errno_location() and __h_errno_location()
  jump through .plt to make older wine happy"

This is probably no help to you Julian (since I guess this is a RH
specific compability patch that won't be included in mainline glibc),
but it certainly makes me happy.

Troels

> -----Original Message-----
> From: val...@li...=20
> [mailto:val...@li...] On Behalf=20
> Of Julian Seward
> Sent: 15. mai 2003 01:13
> To: Tom Hughes; val...@li...
> Subject: Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind
>=20
>=20
>=20
> > This is why wine now deliberately writes a jmp instruction over the
> > first instruction of glibc's internal errno address getting routine
> > so that it guarantee to get control at that point...
>=20
> Well, I've peered at glibc-2.3.2 internals regarding errno=20
> and concluded that it's a *$%*=A3@ nightmare.

Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind

[Tom H. <th...@cy...>]

In message <200...@ac...>
          Julian Seward <js...@ac...> wrote:

> So I peered at the sources for wine-20030508 (a snapshot from a
> couple of days ago).  But after some greppery I cannot find the place
> where this patching is done.  Can you point me in the right place?

It's in scheduler/sysdeps.c in the SYSDEPS_InitErrno function.

Tom

-- 
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/

Re: [Valgrind-users] Compile Valgrind 1.9.6 on Red Hat 9

[Dan K. <da...@ke...>]

Richard Ruth wrote:
> Although I can compile Valgrind on RH7.3 and RH8.0, on
> Red Hat 9 I am getting the following error (both with
> the Red Hat supplied gcc 3.2.2 and the gcc 3.2.3 that
> I built):
> ...
> make: expand.c:489: allocated_variable_append:
> Assertion `current_variable_set_list->next != 0' fail
> ed.

> Any ideas on how to fix this Assertion failure?

google says:
http://mail.gnu.org/archive/html/bug-make/2002-02/msg00056.html

Sure enough, rh9 uses the version of make that report talks
about.  And, bonus deal, it's in their bug tracking system; one
of the hits there even has an easy workaround for you.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89206
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88846

> ------- Additional Comment #1 From Miloslav Trmac on 2003-04-15 08:42 -------
> 
> Workaround when building valgrind:
> instead of just
>      make
> doing
>      env - PATH="$PATH" make
> caused this failure to go away. I haven't been able to find out which
> environment variable was the culprit though.
> ------- Additional Comment #2 From Enrico Scholz on 2003-04-15 09:29 -------
> 
> CPATH is guilty...

Hope that helps.
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind

[Dan K. <da...@ke...>]

Julian Seward wrote:
>>This is why wine now deliberately writes a jmp instruction over the
>>first instruction of glibc's internal errno address getting routine
>>so that it guarantee to get control at that point...
> 
> 
> Well, I've peered at glibc-2.3.2 internals regarding errno and concluded
> that it's a *$%*£@ nightmare.
> 
> Perhaps Wine's brute-force solution is a better way.
> 
> So I peered at the sources for wine-20030508 (a snapshot from a
> couple of days ago).  But after some greppery I cannot find the place
> where this patching is done.  Can you point me in the right place?

Before you do this, could you check with the libc-alpha mailing
list and see what Ulrich Dreper has to say about the best way
to address the issue?  Can't hurt...
- Dan


-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

[Valgrind-users] Compile Valgrind 1.9.6 on Red Hat 9

[Richard R. <ri...@pa...>]

Although I can compile Valgrind on RH7.3 and RH8.0, on
Red Hat 9 I am getting the following error (both with
the Red Hat supplied gcc 3.2.2 and the gcc 3.2.3 that
I built):

valgrind-1.9.6]$ ./configure
--prefix=/usr/local/valgrind --with-x
...
Using the following suppressions by default:

       glibc-2.2.supp xfree-4.supp xfree-3.supp
...
make
...
make[3]: Entering directory
`/dev/shm/valgrind-1.9.6/coregrind'
source='vg_clientfuncs.c' object='vg_clientfuncs.o'
libtool=no \
depfile='.deps/vg_clientfuncs.Po'
tmpdepfile='.deps/vg_clientfuncs.TPo' \
depmode=gcc3 /bin/sh ../depcomp \
/usr/local/gcc/bin/gcc -DHAVE_CONFIG_H -I. -I. -I..
-I./demangle -I../include     -DVG_LIBDIR="\"/us
r/local/valgrind/lib"\" -Winline -Wall -Wshadow -O
-fomit-frame-pointer -mpreferred-stack-boundary=2
 -g -fno-omit-frame-pointer -c `test -f
'vg_clientfuncs.c' || echo './'`vg_clientfuncs.c
make: expand.c:489: allocated_variable_append:
Assertion `current_variable_set_list->next != 0' fail
ed.
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/dev/shm/valgrind-1.9.6/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/dev/shm/valgrind-1.9.6'
make: *** [all] Error 2

Any ideas on how to fix this Assertion failure?

Richard

Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind

[Julian S. <js...@ac...>]

> This is why wine now deliberately writes a jmp instruction over the
> first instruction of glibc's internal errno address getting routine
> so that it guarantee to get control at that point...

Well, I've peered at glibc-2.3.2 internals regarding errno and concluded
that it's a *$%*£@ nightmare.

Perhaps Wine's brute-force solution is a better way.

So I peered at the sources for wine-20030508 (a snapshot from a
couple of days ago).  But after some greppery I cannot find the place
where this patching is done.  Can you point me in the right place?

Thanks,

J

Re: [Valgrind-users] RE: at al loss

[Olly B. <ol...@su...>]

On Wed, May 14, 2003 at 08:27:58AM -0700, Michael Labhard wrote:
> I have been refused connection to the CVS repository with the command:
> 
> cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login
> 
> entering <Enter>, or anonymous or <my-email> at the password prompt.
> 
> How do I get the CVS files?

The valgrind CVS is hosted at sourceforge.net, which tends to be
overloaded at peak times - which usually seems to be during the US
working day.

I'm getting the same problem, and Richard Boulton mentioned it earlier.
All I can suggest is to try later, and if it doesn't resolve itself, to
report the problem to the sourceforge people.

Cheers,
    Olly

[Valgrind-users] RE: at al loss

[Michael L. <in...@pa...>]

I have been refused connection to the CVS repository with the command:

cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login

entering <Enter>, or anonymous or <my-email> at the password prompt.

How do I get the CVS files?

Thank you.

-- Michael

Re: [Valgrind-users] Seemingly wrong reachable-memory reporting

[Crispin F. <cr...@th...>]

On Wed, 2003-05-14 at 13:49, Richard Boulton wrote:
> Wouldn't that result in confusing, or at least excessively repetitive,
> output when the same leak is happening multiple times when called from
> different places?

Hmm I hadn't thought of that :)

> How about changing the leak checker to compare the names up to the first
> name in the stack trace that isn't in part of valgrind?  This would
> exclude the allocation functions quite neatly, which seems desirable.
> Perhaps there are problems with this that I can't see, though.

That seems like a pretty good solution, the slight problem however is
that things such as strdup() aren't provided by valgrind, but will cause
a malloc() to be performed, but the actual location of the leak is in
the function above. (there may only be a small number of functions like
that and these could possibly be special cased to go up another level).

Crispin

Re: [Valgrind-users] Seemingly wrong reachable-memory reporting

[Nicholas N. <nj...@ca...>]

On 14 May 2003, Richard Boulton wrote:

> Incidentally, I was going to try putting a patch for this together, but
> can't seem to update my checkout of valgrind CVS.  In fact, I can't even
> do the cvs login:
>
> $ cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login
> Logging in to :pserver:ano...@cv...:2401/cvsroot/valgrind
> CVS password:
> cvs [login aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: Connection refused
>
> (just pressing return for the password)
>
> Is this just me and the lightning storms around here, or is it sourceforge?

SourceForge does that sometimes, try again or wait a while.

N

Re: [Valgrind-users] Seemingly wrong reachable-memory reporting

[Richard B. <ri...@ta...>]

On Wed, 2003-05-14 at 11:33, Crispin Flowerday wrote:
> Ahh, that explains it. Perhaps the leak-resolution should default to med
> or high as the output was extremely confusing (much worse when you have
> a large application and valgrind has merged 10 blocks into a single
> stacktrace).

Wouldn't that result in confusing, or at least excessively repetitive,
output when the same leak is happening multiple times when called from
different places?

How about changing the leak checker to compare the names up to the first
name in the stack trace that isn't in part of valgrind?  This would
exclude the allocation functions quite neatly, which seems desirable.
Perhaps there are problems with this that I can't see, though.


Incidentally, I was going to try putting a patch for this together, but
can't seem to update my checkout of valgrind CVS.  In fact, I can't even
do the cvs login:

$ cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login
Logging in to :pserver:ano...@cv...:2401/cvsroot/valgrind
CVS password:
cvs [login aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: Connection refused

(just pressing return for the password)

Is this just me and the lightning storms around here, or is it sourceforge?

-- 
Richard

Re: [Valgrind-users] at a loss

[Olly B. <ol...@su...>]

On Wed, May 14, 2003 at 08:41:06AM +0100, Nicholas Nethercote wrote:
> But first, just try "valgrind --leak-check=yes <program>", see how that
> works.

On a slightly tangential note, if your program is built using libtool
(as Michael's was, judging by the program name "src/.libs/lt-myapp") then
running the actual binary in .lib may not work.  The most reliable way
to run it under valgrind would be:

libtool --mode=execute valgrind --leak-check=yes src/myapp

This lets libtool take care of any messing around with environmental
variables and the like that is required to get the program to run
before it has been installed.

The only wrinkle is that --mode=execute seems to have problems with
passing arguments to valgrind or the program in libtool 1.4.2 (you can
set VALGRIND_OPTS to pass options to valgrind).  I've had no such
problems with libtool 1.5.

Cheers,
    Olly

Re: [Valgrind-users] Seemingly wrong reachable-memory reporting

[Crispin F. <cr...@th...>]

> Ah;  by default, the leak checker only compares the first two names in the
> stack trace for the purposes of merging leak record.  Try
> --leak-resolution=med.
> 
> (2.96 gave two leak records because it didn't have the "operator new[]"
> line in the stack trace, so dostuff/dostuff1 made it into the first two
> names.)

Ahh, that explains it. Perhaps the leak-resolution should default to med
or high as the output was extremely confusing (much worse when you have
a large application and valgrind has merged 10 blocks into a single
stacktrace).

Cheers

Crispin

Re: [Valgrind-users] Seemingly wrong reachable-memory reporting

[Nicholas N. <nj...@ca...>]

On Wed, 14 May 2003, Nicholas Nethercote wrote:

> > While attempting to locate all the memory in a program that wasn't
> > freed, I came across an odd behaviour.

[snip]

> > (compiled with gcc 3.2.3 (debian unstable), using 'g++ main.cpp-o main'
> >
> > I get only 2 unreachable blocks, but both with the same stacktrace:
> >
> > 2048 bytes in 2 blocks are still reachable in loss record 1 of 1
> >    at 0x4015D573: __builtin_vec_new (vg_clientfuncs.c:161)
> >    by 0x4015D5AE: operator new[](unsigned) (vg_clientfuncs.c:174)
> >    by 0x8048450: do_stuff() (in /home/crispin/src/tmp/main)
> >    by 0x8048470: main (in /home/crispin/src/tmp/main)
> >
> > Surely I should get 2 different stacktraces?
>
> I get the same with gcc 3.2.3.  But with gcc 2.96 I get two stack traces.
> Hmm, not sure...

Ah;  by default, the leak checker only compares the first two names in the
stack trace for the purposes of merging leak record.  Try
--leak-resolution=med.

(2.96 gave two leak records because it didn't have the "operator new[]"
line in the stack trace, so dostuff/dostuff1 made it into the first two
names.)

N

Re: [Valgrind-users] Seemingly wrong reachable-memory reporting

[Bastien C. <ba...@ch...>]

On Wednesday 14 May 2003 11:58, Crispin Flowerday wrote:
> No, I just get a longer stacktrace :)

Confirmed :-/ (with valgrind 1.9.5 and gcc3.3) Compiling with -g didn't help 
either, it really shows the same line for both leaks. As no optimization 
option is used for the compiler, I'd say that it's a bug. Now whether it's 
the compiler or valgrind ...

Salut,
      Bastien

-- 
        -- The universe has its own cure for stupidity. --
         -- Unfortunately, it doesn't always apply it. --

Re: [Valgrind-users] Seemingly wrong reachable-memory reporting

[Nicholas N. <nj...@ca...>]

On 14 May 2003, Crispin Flowerday wrote:

> While attempting to locate all the memory in a program that wasn't
> freed, I came across an odd behaviour.
>
> Using the following program:
>
> == START ==
>
> static char * bar = 0;
> static char * bar1 = 0;
>
> void do_stuff1()
> {
>    bar = new char[1024];
> }
>
> void do_stuff()
> {
>    bar1 = new char[1024];
> }
>
> int main( int argc, char ** argv )
> {
>    do_stuff();
>    do_stuff1();
> }
>
> == END ==
>
> (compiled with gcc 3.2.3 (debian unstable), using 'g++ main.cpp-o main'
>
> I get only 2 unreachable blocks, but both with the same stacktrace:
>
> 2048 bytes in 2 blocks are still reachable in loss record 1 of 1
>    at 0x4015D573: __builtin_vec_new (vg_clientfuncs.c:161)
>    by 0x4015D5AE: operator new[](unsigned) (vg_clientfuncs.c:174)
>    by 0x8048450: do_stuff() (in /home/crispin/src/tmp/main)
>    by 0x8048470: main (in /home/crispin/src/tmp/main)
>
> Surely I should get 2 different stacktraces?

I get the same with gcc 3.2.3.  But with gcc 2.96 I get two stack traces.
Hmm, not sure...

N

Re: [Valgrind-users] Seemingly wrong reachable-memory reporting

[Crispin F. <cr...@th...>]

On Wed, 2003-05-14 at 10:45, Bastien Chevreux wrote:
> On Wednesday 14 May 2003 11:37, Crispin Flowerday wrote:
> > While attempting to locate all the memory in a program that wasn't
> > freed, I came across an odd behaviour.
> > [...]
> > I get only 2 unreachable blocks, but both with the same stacktrace:
> 
> Does using the --num-callers option help?

No, I just get a longer stacktrace :)

Crispin

Re: [Valgrind-users] Seemingly wrong reachable-memory reporting

[Bastien C. <ba...@ch...>]

On Wednesday 14 May 2003 11:37, Crispin Flowerday wrote:
> While attempting to locate all the memory in a program that wasn't
> freed, I came across an odd behaviour.
> [...]
> I get only 2 unreachable blocks, but both with the same stacktrace:

Does using the --num-callers option help?

Salut,
       Bastien

-- 
        -- The universe has its own cure for stupidity. --
         -- Unfortunately, it doesn't always apply it. --

[Valgrind-users] Seemingly wrong reachable-memory reporting

[Crispin F. <cr...@th...>]

Hi,

While attempting to locate all the memory in a program that wasn't
freed, I came across an odd behaviour.

Using the following program:

== START ==

static char * bar = 0;
static char * bar1 = 0;

void do_stuff1()
{
   bar = new char[1024];
}

void do_stuff()
{
   bar1 = new char[1024];
}

int main( int argc, char ** argv )
{
   do_stuff();
   do_stuff1();
}

== END ==

(compiled with gcc 3.2.3 (debian unstable), using 'g++ main.cpp-o main'

I get only 2 unreachable blocks, but both with the same stacktrace:

2048 bytes in 2 blocks are still reachable in loss record 1 of 1
   at 0x4015D573: __builtin_vec_new (vg_clientfuncs.c:161)
   by 0x4015D5AE: operator new[](unsigned) (vg_clientfuncs.c:174)
   by 0x8048450: do_stuff() (in /home/crispin/src/tmp/main)
   by 0x8048470: main (in /home/crispin/src/tmp/main)

Surely I should get 2 different stacktraces?

Cheers