Electric Fence - still reliable?

Michael Schwendt mschwendt at gmail.com
Fri Dec 18 18:47:50 UTC 2009


On Fri, 18 Dec 2009 09:47:02 -0800, John wrote:

> > [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.

I need to correct myself then. With "It just reported way too much here" I
wanted to refer to its output in general, not only to the output quoted
above. For example, with some programs I examined with valgrind with
default options, I saw multiple hundreds of such sections, referring to
several libraries. Compared with that I liked it that efence stopped at
the first error and ABRT collected the crash details.




More information about the fedora-devel-list mailing list