Re: tcmalloc compatibility

[ardi <ardillasdelmonte@gmail.com>]

On Tue, Apr 10, 2018 at 11:17 PM, Szabolcs Nagy <nsz@port70.net> wrote:
>
> then the wrappers with dlsym(RTLD_NEXT,sym) would not work.
> (malloc checkers, valgrind, sanitizers etc all do it)

I've been using ElectricFence, as my only memory debugger since 1996
or so; mostly with the libc of commercial Unices, but also with glibc
in Linux, and with the OSX libc. I never considered I could run into
the issues commented in this thread, and in fact I never faced these
issues and it always worked as expected (however, I must admit I only
use multithreading for accelerating clearly isolated math-intensive
loops that don't call malloc-related functions from inside the loop).

Said this, when I'm linking with ElectricFence, my brain has the "hack
mode flag" ON (I mean, I always had the feeling that I'm working with
a temporary hack that can fail whenever my link line contains -lefence
, and I'm aware that things can go wrong --I didn't consider thread
safety, but anyway I know ElectricFence can fail if the OS syscalls
that allocate protected memory at buffer ends change their behaviour
in newer versions, or if there's some OS/CPU-dependent subtlety with
alignment, etc...)

I've not tried to use ElectricFence with musl yet... but reading this,
can I suppose it won't work? Is there any "hack mode ON" procedure
(yet easy) that would allow to use ElectricFence (assuming
non-threaded code, which is always my case).

I agree with your commitment to correctness, and I'm not asking for a
safe and guaranteed implementation of function interposition, just
that sometimes I need to break my binaries to make them crash hard as
soon as pointer accesses a byte it shouldn't access.

Cheers,

ardi