Electric Fence - still reliable?

[Michael Schwendt]

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. I examined some uninitialised variables with Valgrind
yesterday.  For a couple of other cases (including Audacious), comparison
is the goal here,

  $ valgrind w 2>&1|wc -l
  238
  $ valgrind --leak-check=full w 2>&1|wc -l
  249

versus

  $ ef w 2>&1|wc -l
  3

with the latter triggering ABRT activity, whereas the former 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.