Re: Running bash under valgrind gives "invalid free()"

[Reuben Thomas]

On 12 April 2017 at 17:58, Hanno Böck  wrote:

> On Wed, 12 Apr 2017 14:59:26 +0100
> Reuben Thomas  wrote:
>
> > ​frequently, it's the only tool that shows up bugs of this sort, as
> > it's rather more powerful than a debugging malloc library.)
>
> Try address sanitizer, it's pretty reliable and finds even more bug
> classes compared to valgrind. Just add -fsanitize=address to the CFLAGS.
>
> If you can't reproduce the bug with asan I'd bet on a valgrind bug.


​Thanks very much for the recommendation (and to Chet); I'd not heard of
it. Once I've fixed all the bugs I'm finding with valgrind, I'll go back
and see what asan finds, and also see if it finds anything else, so I can
see whether to run it as well or instead of valgrind.

Having confirmed Chet's analysis with a few printfs added to bash (i.e.
just to check the address being allocated and the one complained about were
the same) I've filed a bug report against valgrind:
https://bugs.kde.org/show_bug.cgi?id=378732

-- 
http://rrt.sc3d.org

Re: Running bash under valgrind gives "invalid free()"

[Reuben Thomas]

On 13 April 2017 at 09:15, Reuben Thomas  wrote:

>
> Having confirmed Chet's analysis with a few printfs added to bash (i.e.
> just to check the address being allocated and the one complained about were
> the same) I've filed a bug report against valgrind:
> https://bugs.kde.org/show_bug.cgi?id=378732
>

​Julian Seward (valgrind author) correctly​

​guessed that it is a problem with malloc/free interception: when bash uses
its own malloc (as by default on my GNU/Linux system), the malloc is not
intercepted by valgrind, but the free is.

Obviously a bug in valgrind, but I am interested: why does bash not use the
glibc malloc by default on GNU/Linux systems?

-- 
http://rrt.sc3d.org

Re: Running bash under valgrind gives "invalid free()"

[Chet Ramey]

On 4/13/17 6:32 AM, Reuben Thomas wrote:

> Obviously a bug in valgrind, but I am interested: why does bash not use the
> glibc malloc by default on GNU/Linux systems?

The bash malloc is faster; better tuned for bash; is more signal safe
without the twisty maze of locks that the glibc malloc uses; and includes
things like bounds checking and duplicate free detection by default.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Running bash under valgrind gives "invalid free()"

[Reuben Thomas]

On 12 April 2017 at 15:49, Chet Ramey  wrote:

>
> It's a false positive, or a bug in valgrind. I took a quick look.  There's
> one place in this code path where free() gets called.


​Julian Seward (valgrind author) pointed out:​

"
​…​
what you report is symptomatic of bash
​ ​
using its own malloc to allocate a block but the system free to release
​ ​
it.  Could that be the case?
​"

I had a look. Certainly at xmalloc.c:148 where free is called by xfree from
the cleanup function called at unwind_prot.c:333, gdb reports:

p free
$7 = {void (void *)} 0x77df0d80 

This is glibc free.

If I put a breakpoint on xmalloc and rerun, it is not hit.

If I put a breakpoint on shell.c:1399, and trace into savestring, I find it
is running sh_xmalloc.

So it seems that the malloc and free calls are mismatched.

Re: Running bash under valgrind gives "invalid free()"

[Reuben Thomas]

​O​
n 13 April 2017 at 15:33, Reuben Thomas  wrote:

> On 12 April 2017 at 15:49, Chet Ramey  wrote:
>
>>
>> It's a false positive, or a bug in valgrind. I took a quick look.  There's
>> one place in this code path where free() gets called.
>
>
> ​Julian Seward (valgrind author) pointed out:​
>
> "
> ​…​
> what you report is symptomatic of bash
> ​ ​
> using its own malloc to allocate a block but the system free to release
> ​ ​
> it.  Could that be the case?
> ​"
>
> I had a look. Certainly at xmalloc.c:148 where free is called by xfree
> from the cleanup function called at unwind_prot.c:333, gdb reports:
>
> p free
> $7 = {void (void *)} 0x77df0d80 
>
> This is glibc free.
>
> If I put a breakpoint on xmalloc and rerun, it is not hit.
>
> If I put a breakpoint on shell.c:1399, and trace into savestring, I find
> it is running sh_xmalloc.
>
> So it seems that the malloc and free calls are mismatched.
>

​Trying to understand this at a source level, if I capture the compilation
command for evalstring.c​ and replace -c with -E to preprocess it, I see
that the relevant line has become:

add_unwind_protect (xfree, orig_string)

where xfree is now the function name (in xmalloc.c).

So this still looks wrong (it should be sh_xfree, surely?).

-- 
http://rrt.sc3d.org

Re: Running bash under valgrind gives "invalid free()"

[Chet Ramey]

On 4/13/17 10:33 AM, Reuben Thomas wrote:
> On 12 April 2017 at 15:49, Chet Ramey  > wrote:
> 
> 
> It's a false positive, or a bug in valgrind. I took a quick look.  There's
> one place in this code path where free() gets called.
> 
> 
> ​Julian Seward (valgrind author) pointed out:​
> 
> "
> ​…​
> what you report is symptomatic of bash
> ​ ​
> using its own malloc to allocate a block but the system free to release
> ​ ​
> it.  Could that be the case?

I doubt it.

> ​"
> 
> I had a look. Certainly at xmalloc.c:148 where free is called by xfree from
> the cleanup function called at unwind_prot.c:333, gdb reports:
> 
> p free
> $7 = {void (void *)} 0x77df0d80 
> 
> This is glibc free.
> 
> If I put a breakpoint on xmalloc and rerun, it is not hit.
> 
> If I put a breakpoint on shell.c:1399, and trace into savestring, I find it
> is running sh_xmalloc.

sh_xmalloc is just a wrapper that calls sh_malloc, in the same way that
xmalloc calls malloc.  sh_malloc is, in turn, a wrapper around bash's
internal malloc that adds file and line tracing information to the call.
The bash malloc() implementation simply calls this internal_malloc without
the file and line information.  You can freely mix calls to sh_malloc
and malloc without arena corruption.  It's easy to see what happens: the
bash calls get tracing, and malloc calls from libraries don't.  This is
exactly what you want.

Ths same thing happens with free: sh_xfree is a wrapper around sh_free
as xfree wraps free; sh_free is a wrapper that adds file and line
tracing to free.  The bash free() is a wrapper that calls internal_free
in the same fashion.

The normal bash allocation calls use these wrappers (defined in xmalloc.h)
so the tracing takes place and the trace information appears in error
messages, and can be optionally logged.

It doesn't make sense to do this in the unwind-protect calls because you're
calling through function pointers, so bash uses xfree. xfree calls free,
and doesn't require you to know whether free is a void or int function
(which used to matter more than it does now, but still matters on some
systems).  free is defined in the same file in the same (statically-
linked) library as the rest of the bash malloc functions.

I see no reason why, since all of these things are defined in the same
file and are statically linked, `free' would resolve to the glibc free
when malloc resolves to the bash malloc.

> So it seems that the malloc and free calls are mismatched.

Only in that they don't use the fixed names `malloc' and `free'.  If you
replace one set of names without the other, you'll produce false positives.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Running bash under valgrind gives "invalid free()"

[Chet Ramey]

On 4/13/17 10:55 AM, Reuben Thomas wrote:

> ​Trying to understand this at a source level, if I capture the compilation
> command for evalstring.c​ and replace -c with -E to preprocess it, I see
> that the relevant line has become:
> 
> add_unwind_protect (xfree, orig_string)
> 
> where xfree is now the function name (in xmalloc.c).
> 
> So this still looks wrong (it should be sh_xfree, surely?).

No. See my previous message for how these functions fit together.  You
don't want tracing information from xfree, since it's misleading when
called via a function pointer from the unwind-protect code.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Running bash under valgrind gives "invalid free()"

[Reuben Thomas]

On 13 April 2017 at 16:11, Chet Ramey  wrote:

>
> I see no reason why, since all of these things are defined in the same
> file and are statically linked, `free' would resolve to the glibc free
> when malloc resolves to the bash malloc.


So this is the real problem?​

​Do you have any suggestions for how I might investigate this?​

-- 
http://rrt.sc3d.org

Re: Running bash under valgrind gives "invalid free()"

[Chet Ramey]

On 4/13/17 11:18 AM, Reuben Thomas wrote:
> On 13 April 2017 at 16:11, Chet Ramey  > wrote:
> 
> 
> I see no reason why, since all of these things are defined in the same
> file and are statically linked, `free' would resolve to the glibc free
> when malloc resolves to the bash malloc.
> 
> 
> So this is the real problem?​

If it is, it's a valgrind artifact.  Contrary to Julian's (?) assumption,
free() resolves to the bash free implementation when compiled normally. I
tested this on a Fedora 25 VM I was using for something else.  Putting a
breakpoint in xfree, running bash -c '', and stepping through it ends up
in the free() defined in lib/malloc/malloc.c.

>  
> ​Do you have any suggestions for how I might investigate this?​

Personally, I think the problem is that valgrind makes invalid assumptions:
that interposing malloc/realloc/free is sufficient.  I showed it isn't.

You can try building without the bash malloc, but that's kind of a drastic
solution to just get rid of a valgrind false positive.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Running bash under valgrind gives "invalid free()"

[Reuben Thomas]

​O​
n 13 April 2017 at 16:27, Chet Ramey  wrote:

> On 4/13/17 11:18 AM, Reuben Thomas wrote:
> > On 13 April 2017 at 16:11, Chet Ramey  > > wrote:
> >
> >
> > I see no reason why, since all of these things are defined in the
> same
> > file and are statically linked, `free' would resolve to the glibc
> free
> > when malloc resolves to the bash malloc.
> >
> >
> > So this is the real problem?​
>
> If it is, it's a valgrind artifact.  Contrary to Julian's (?) assumption,
> free() resolves to the bash free implementation when compiled normally. I
> tested this on a Fedora 25 VM I was using for something else.  Putting a
> breakpoint in xfree, running bash -c '', and stepping through it ends up
> in the free() defined in lib/malloc/malloc.c.
>

​This is not the result I obtained. I simply ran gdb on the bash binary,
valgrind was not involved.​

​Indeed, building --without-bash-malloc fixed it.​

Re: Running bash under valgrind gives "invalid free()"

[Chet Ramey]

On 4/13/17 11:41 AM, Reuben Thomas wrote:

> ​This is not the result I obtained. I simply ran gdb on the bash binary,
> valgrind was not involved.​

If you didn't build the binary yourself, you don't know what changes were
made to it.  Here's what I got on Fedora 25.

[chet@caleb-fedora25 bash-20170407]$ ./bash --version
GNU bash, version 4.4.12(1)-maint (x86_64-unknown-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
[chet@caleb-fedora25 bash-20170407]$ gdb ./bash
GNU gdb (GDB) Fedora 7.12-24.fc25
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./bash...done.
(gdb) b xfree
Breakpoint 1 at 0x47e180: file /home/chet/src/bash-20170407/xmalloc.c, line
147.
(gdb) r -c ''
Starting program: /home/chet/build/bash-20170407/bash -c ''
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.24-3.fc25.x86_64

Breakpoint 1, xfree (string=0x7bd218)
at /home/chet/src/bash-20170407/xmalloc.c:147
147   if (string)
Missing separate debuginfos, use: dnf debuginfo-install
ncurses-libs-6.0-6.20160709.fc25.x86_64
(gdb) s
148 free (string);
(gdb) s
free (mem=0x7bd218) at /home/chet/src/bash-20170407/lib/malloc/malloc.c:1338
1338  internal_free (mem,  (char *)NULL, 0, 0);
(gdb) s
internal_free (mem=0x7bd218, file=0x0, line=0, flags=0)
at /home/chet/src/bash-20170407/lib/malloc/malloc.c:868
868   if ((ap = (char *)mem) == 0)
(gdb)


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Running bash under valgrind gives "invalid free()"

[Chet Ramey]

On 4/13/17 11:46 AM, Chet Ramey wrote:
> On 4/13/17 11:41 AM, Reuben Thomas wrote:
> 
>> ​This is not the result I obtained. I simply ran gdb on the bash binary,
>> valgrind was not involved.​
> 
> If you didn't build the binary yourself, you don't know what changes were
> made to it.  Here's what I got on Fedora 25.

And before anyone asks, here's what I got on Debian 8 with bash-4.4.12,
built from source.

chet@debian8-caleb:~/build/bash-4.4.12$ ./bash --version
GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
chet@debian8-caleb:~/build/bash-4.4.12$ gdb ./bash
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./bash...done.
(gdb) b xfree
Breakpoint 1 at 0x4799b0: file /home/chet/src/bash-4.4.12/xmalloc.c, line 147.
(gdb) r -c ''
Starting program: /home/chet/build/bash-4.4.12/bash -c ''

Breakpoint 1, xfree (string=0x71d1c8)
at /home/chet/src/bash-4.4.12/xmalloc.c:147
147   if (string)
(gdb) where
#0  xfree (string=0x71d1c8) at /home/chet/src/bash-4.4.12/xmalloc.c:147
#1  0x0046194c in unwind_frame_run_internal (
tag=0x4d67e9 "parse_and_execute top", ignore=0x0)
at /home/chet/src/bash-4.4.12/unwind_prot.c:333
#2  0x00461d60 in without_interrupts (arg2=,
arg1=, function=)
at /home/chet/src/bash-4.4.12/unwind_prot.c:123
#3  run_unwind_frame (tag=0x71d1c8 "",
tag@entry=0x4d67e9 "parse_and_execute top")
at /home/chet/src/bash-4.4.12/unwind_prot.c:151
#4  0x0047ff99 in parse_and_execute (string=,
from_file=from_file@entry=0x4c0905 "-c", flags=flags@entry=4)
at /home/chet/src/bash-4.4.12/builtins/evalstring.c:455
#5  0x0041f4ba in run_one_command (command=)
at /home/chet/src/bash-4.4.12/shell.c:1399
#6  0x00421122 in main (argc=3, argv=0x7fffe368,
env=0x7fffe388) at /home/chet/src/bash-4.4.12/shell.c:724
(gdb) s
148 free (string);
(gdb) s
free (mem=0x71d1c8) at /home/chet/src/bash-4.4.12/lib/malloc/malloc.c:1273
1273  internal_free (mem,  (char *)NULL, 0, 0);
(gdb) s
internal_free (mem=0x71d1c8, file=0x0, line=0, flags=)
at /home/chet/src/bash-4.4.12/lib/malloc/malloc.c:846
846 internal_free (mem, file, line, flags)
(gdb)



-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Running bash under valgrind gives "invalid free()"

[Reuben Thomas]

On 13 April 2017 at 16:46, Chet Ramey  wrote:

> On 4/13/17 11:41 AM, Reuben Thomas wrote:
>
> > ​This is not the result I obtained. I simply ran gdb on the bash binary,
> > valgrind was not involved.​
>
> If you didn't build the binary yourself,


​I did, from git master. Sorry that wasn't clear.​

​Thanks for your gdb traces.

Here's mine on Ubuntu 16.04:

$ ./bash --version
GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ gdb ./bash
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./bash...done.
(gdb) b xfree
Breakpoint 1 at 0x47ca80: file xmalloc.c, line 147.
(gdb) r -c ''
Starting program: /home/rrt/.local/var/repo/bash/bash -c ''
s is  0x721368
s is  0x721368
string is  0x721368

Breakpoint 1, xfree (string=0x721368) at xmalloc.c:147
147  if (string)
(gdb) s
148free (string);
(gdb) s
internal_free (mem=0x721368, file=0x0, line=0, flags=) at
malloc.c:846
846malloc.c: No such file or directory.
(gdb) s
858in malloc.c
(gdb) p free
$1 = {void (void *)} 0x77df0d80 
(gdb)

So it seems I misunderstood what gdb was telling me: "p free" gives the
address of glibc free (even if I do it inside xfree). But it is running
bash's free.

(There are some extra diagnostics there which are debugging statements I
put in.)

Meanwhile, in the valgrind bug report, Mark Wielaard observed:

"I think the problem is that bash not only has its own malloc/free
implementation (valgrind should intercept that just fine). But also has
malloc wrappers for some malloc functions that call their internal
counterparts directly (so valgrind won't know that is a matching
allocation/deallocation function)."

Mark manages to fix the problem by defining DISABLE_MALLOC_WRAPPERS, which
is at least less drastic than configuring --without-bash-malloc.

I shall pursue the matter on the Valgrind side. Mark also says that
compiled thus he finds some small memory leaks in bash, so I'll report back
if I can confirm.

Thanks very much again for your help with this problem.

-- 
http://rrt.sc3d.org

Leaks detected by valgrind

[Reuben Thomas]

Here they are. I guess you probably won't care about them as as far as I
can see they are all one-off allocations at initialization:

==1289== 276 bytes in 1 blocks are definitely lost in loss record 230 of 249
==1289==at 0x4C2DB2F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1289==by 0x4793CF: xmalloc (xmalloc.c:112)
==1289==by 0x472F48: set_default_locale (locale.c:81)
==1289==by 0x420900: main (shell.c:411)
==1289==
==1289== 1,008 bytes in 1 blocks are definitely lost in loss record 232 of
249
==1289==at 0x4C2DB2F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1289==by 0x47939A: xmalloc (xmalloc.c:112)
==1289==by 0x496FDD: sh_setlinebuf (setlinebuf.c:45)
==1289==by 0x41F83C: shell_initialize (shell.c:1799)
==1289==by 0x4210BB: main (shell.c:570)
==1289==
==1289== 1,008 bytes in 1 blocks are definitely lost in loss record 233 of
249
==1289==at 0x4C2DB2F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1289==by 0x47939A: xmalloc (xmalloc.c:112)
==1289==by 0x496FDD: sh_setlinebuf (setlinebuf.c:45)
==1289==by 0x41F848: shell_initialize (shell.c:1800)
==1289==by 0x4210BB: main (shell.c:570)
==1289==

-- 
http://rrt.sc3d.org

Re: Running bash under valgrind gives "invalid free()"

[Chet Ramey]

On 4/13/17 3:57 PM, Reuben Thomas wrote:

> Meanwhile, in the valgrind bug report, Mark Wielaard observed:
> 
> "I think the problem is that bash not only has its own malloc/free
> implementation (valgrind should intercept that just fine). But also has
> malloc wrappers for some malloc functions that call their internal
> counterparts directly (so valgrind won't know that is a matching
> allocation/deallocation function)."

Yes, if he wants the details, feel free to forward my message from earlier
today.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Leaks detected by valgrind

[Chet Ramey]

On 4/13/17 4:12 PM, Reuben Thomas wrote:
> Here they are. I guess you probably won't care about them as as far as I
> can see they are all one-off allocations at initialization:
> 
> ==1289== 276 bytes in 1 blocks are definitely lost in loss record 230 of 249
> ==1289==at 0x4C2DB2F: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==1289==by 0x4793CF: xmalloc (xmalloc.c:112)
> ==1289==by 0x472F48: set_default_locale (locale.c:81)
> ==1289==by 0x420900: main (shell.c:411)

This one is interesting. It's come up before. Bash makes a copy of the
default locale (as returned by setlocale()) for its own purposes.  Some
systems use a static buffer for that value; some systems, including glibc,
return allocated memory (even though the man page warns to not assume
anything about the returned string).

You're right about the two buffers for setlinebuf().

Thanks.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Running bash under valgrind gives "invalid free()"

[Reuben Thomas]

On 13 April 2017 at 21:17, Chet Ramey  wrote:

> On 4/13/17 3:57 PM, Reuben Thomas wrote:
>
> > Meanwhile, in the valgrind bug report, Mark Wielaard observed:
> >
> > "I think the problem is that bash not only has its own malloc/free
> > implementation (valgrind should intercept that just fine). But also has
> > malloc wrappers for some malloc functions that call their internal
> > counterparts directly (so valgrind won't know that is a matching
> > allocation/deallocation function)."
>
> Yes, if he wants the details, feel free to forward my message from earlier
> today.
>

​Thanks, I
​ already linked to it in the valgrind bug report
.​

​​
-- 
http://rrt.sc3d.org