|
From: Eyal L. <ey...@ey...> - 2003-03-20 07:55:34
|
I get the following report on program shutdown: ==10648== Time: 2003/03/20 18:05:19 ==10648== Invalid free() / delete / delete[] ==10648== at 0x4015E2CD: free (vg_clientfuncs.c:182) ==10648== by 0x42B5DB6B: (within /lib/libc-2.2.93.so) ==10648== by 0x42ACA021: __libc_freeres (in /lib/libc-2.2.93.so) ==10648== by 0x4015EADD: vgPlain___libc_freeres_wrapper (vg_clientfuncs.c:587) ==10648== by 0x42A7C208: exit (in /lib/libc-2.2.93.so) ==10648== by 0x429C682D: ??? (exit.c:216) ==10648== by 0x429D467F: skmain (main.c:1098) ==10648== by 0x8050462: main (ssasrsv.c:789) ==10648== by 0x42A66913: __libc_start_main (in /lib/libc-2.2.93.so) ==10648== by 0x804E3D0: (within /home/eyal/a1i/bin/ssasrsv.orig) ==10648== Address 0x42A2A830 is not stack'd, malloc'd or free'd The stamenet at exit.c:216 is 'exit (0)'. What are the possible causes of this? -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Nicholas N. <nj...@ca...> - 2003-03-24 12:16:17
|
On Thu, 20 Mar 2003, Eyal Lebedinsky wrote:
> I get the following report on program shutdown:
>
> ==10648== Time: 2003/03/20 18:05:19
> ==10648== Invalid free() / delete / delete[]
> ==10648== at 0x4015E2CD: free (vg_clientfuncs.c:182)
> ==10648== by 0x42B5DB6B: (within /lib/libc-2.2.93.so)
> ==10648== by 0x42ACA021: __libc_freeres (in /lib/libc-2.2.93.so)
> ==10648== by 0x4015EADD: vgPlain___libc_freeres_wrapper
> (vg_clientfuncs.c:587)
> ==10648== by 0x42A7C208: exit (in /lib/libc-2.2.93.so)
> ==10648== by 0x429C682D: ??? (exit.c:216)
> ==10648== by 0x429D467F: skmain (main.c:1098)
> ==10648== by 0x8050462: main (ssasrsv.c:789)
> ==10648== by 0x42A66913: __libc_start_main (in /lib/libc-2.2.93.so)
> ==10648== by 0x804E3D0: (within /home/eyal/a1i/bin/ssasrsv.orig)
> ==10648== Address 0x42A2A830 is not stack'd, malloc'd or free'd
>
> The stamenet at exit.c:216 is 'exit (0)'.
>
> What are the possible causes of this?
From the most recent docs:
<li><code>--run-libc-freeres=yes</code> [the default]<br>
<code>--run-libc-freeres=no</code>
<p>The GNU C library (<code>libc.so</code>), which is used by
all programs, may allocate memory for its own uses. Usually it
doesn't bother to free that memory when the program ends - there
would be no point, since the Linux kernel reclaims all process
resources when a process exits anyway, so it would just slow
things down.
<p>
The glibc authors realised that this behaviour causes leak
checkers, such as Valgrind, to falsely report leaks in glibc,
when a leak check is done at exit. In order to avoid this, they
provided a routine called <code>__libc_freeres</code>
specifically to make glibc release all memory it has allocated.
The MemCheck and AddrCheck skins therefore try and run
<code>__libc_freeres</code> at exit.
<p>
Unfortunately, in some versions of glibc,
<code>__libc_freeres</code> is sufficiently buggy to cause
segmentation faults. This is particularly noticeable on Red Hat
7.1. So this flag is provided in order to inhibit the run of
<code>__libc_freeres</code>. If your program seems to run fine
on valgrind, but segfaults at exit, you may find that
<code>--run-libc-freeres=no</code> fixes that, although at the
cost of possibly falsely reporting space leaks in
<code>libc.so</code>.
</li><br><p>
Hope this explains it.
N
|