Electric Fence - still reliable?

[John Reiser]

On 12/18/2009 08:19 AM, Michael Schwendt wrote:
> On Fri, 18 Dec 2009 15:57:31 +0000, Bastien wrote:
>
>> I'm not sure even trying to use ElectricFence is such a good idea
>> anyway, when we have valgrind available.
>
> Yeah, likely.

Both can be useful.  The speed overhead of ElectricFence is a couple percent,
whereas valgrind(memcheck) slows execution by a *factor* of 10 to 20.

>
> [ElectricFence] triggering ABRT activity, whereas [Valgrind] requires
> increased effort to make sense of undetailed traces such as the following
> (which is bug 548711):
>
> ==13516== Invalid read of size 1
> ==13516==    at 0x400730E: strcmp (mc_replace_strmem.c:426)
> ==13516==    by 0x8D63A6: _nl_find_locale (findlocale.c:94)
> ==13516==    by 0x8D597B: setlocale (setlocale.c:409)
> ==13516==    by 0xA348D1: loadavg (in /lib/libproc-3.2.8.so)
> ==13516==    by 0xA35C4B: sprint_uptime (in /lib/libproc-3.2.8.so)
> ==13516==    by 0xA35CF7: print_uptime (in /lib/libproc-3.2.8.so)
> ==13516==    by 0x80497E4: ??? (in /usr/bin/w)
> ==13516==    by 0x8CBBB5: (below main) (libc-start.c:226)
> ==13516==  Address 0x4053528 is 0 bytes inside a block of size 12 free'd
> ==13516==    at 0x40057F6: free (vg_replace_malloc.c:325)
> ==13516==    by 0x8D5A1B: setlocale (setlocale.c:203)
> ==13516==    by 0xA3488E: loadavg (in /lib/libproc-3.2.8.so)
> ==13516==    by 0xA35C4B: sprint_uptime (in /lib/libproc-3.2.8.so)
> ==13516==    by 0xA35CF7: print_uptime (in /lib/libproc-3.2.8.so)
> ==13516==    by 0x80497E4: ??? (in /usr/bin/w)
> ==13516==    by 0x8CBBB5: (below main) (libc-start.c:226)
> ==13516==
>
> I'm sure I could install lots of missing -debuginfo packages manually
> and tweak valgrind options. It just reported way too much here.

This complaint is way off base.  It complains "undetailed" and "reported
way too much" for the same case, which is contradictory.

The report gives traceback both for the immediate error and for the cause
which happened long ago.  Some file and line numbers have been omitted,
but those are not needed to pinpoint the error: setlocale() called
free() but afterwards setlocale() still used the block which was freed.
The bug is in setlocale or in the parameters passed to it by loadavg().
If the problem is in loadavg(), then the tracebacks provide clues
to the environment in which loadavg() erred.  This report from memcheck
is close to ideal.

--