Re: mtrace perl tool reporting "+ 0x000001003c393dc0 Alloc 3183 duplicate: 0x3fffaa678d08 /lib64/libntirpc.so.1.3:[0x3fffaa678d08]"

[Carlos O'Donell <carlos at redhat dot com>]

On 2/21/19 3:34 PM, Malahal Naineni wrote:
>>> The serializing lock in all the tr_*hook functions should ensure that you see the correct order.
> 
> Looked at the tr_freehook() source. It changes __free_hook just before
> calling real free(). So if 2 threads call free() at the same time, one
> free() may call the tr_freehook() and this will acquire a lock and
> change the __free_hook to tr_old_free_hook which is NULL. The second
> thread's free() call may see this NULL hook and never really logs
> anything to the trace file. I think mtrace() hooks don't work with
> multithreaded application, pretty useless in multithreaded
> applications. Am I wrong?

Ugh, sorry, I forgot all about this code.

You are correct.

And `info libc "Tracing Malloc"` shows that mtrace() is MT-Unsafe
(harmonized info is in `man mtrace` which shows MT-unsafe).

DJ, Florian, and I wrote a thread-safe tracer that we used for
the tracing and simulation work we presented in LPC 2016, but we
haven't merged it upstream into master yet.

I expect the new tracer to replace the old tracer and operate as
an interposed library, and be thread safe.

First I need to cleanup and remove the old hooks so core malloc
can run faster when not under trace.

Sorry for the confusion.

-- 
Cheers,
Carlos.