152353 - Suggestion for trace-malloc

Status: RESOLVED INCOMPLETE

(Core :: XPCOM, enhancement)

Description

[tenthumbs]

On Linux dladdr is slow. It does a linear search through a symbol table 
for each candidate library. It also has no memory so it plows through 
the same tables over and over again. The obvious solution is to not do 
that. :-)

This is actually possible. Only the run-time location of a library is in 
doubt. Everything else is part of the ELF structure which can be read 
independently. All you really need is find is the base address of a 
candidate library and its file name. You just write that out and do the 
rest later.

Now my_dladdr already exists. You just need the first part (with a few 
minor changes).

This will speed things up but the true win is that you can access other 
symbol tables so you can potentially find static functions, etc.

And yes, this approach does seem to work.

Comment 1

[Doug Turner (:dougt)]

mostly blames to brendan.

Comment 2

[Brendan Eich [:brendan]]

Tenthumbs, do you have a patch?  If so, please attach.

I'm giving this bug to bryner cuz he's been working on trace-malloc speedups
recently; cc'ing dbaron, who is always up for trace-malloc fun.

/be

Comment 3

[tenthumbs]

No patches yet, it too early.

I've been working on my own malloc tool on and off for a while so I do 
know some things. Using a replacement dladdr speeds up things at least 5 
times. Searching the symbol tables is really slow. We won't gain 
anything overall if we analyze the libraries the same way later on. The 
approach I'm beginning to like is to read an ELF executable, find the 
symbol tables, extract only the symbols of interest, merge all the 
symbols keeping track of where they came from etc., sorting the result 
by address, saving this derived data to disk, and reusing it as needed. 
There are a few quirks, though. Some addresses have multiple symbols. My 
libc has six names for fopen so picking the right name is a little 
tricky. Right now I'm contemplating how to arrange the derived data

Comment 4

[tenthumbs]

Attachment: example

Here's an example with my own tool. It's one malloc call with a backtrace. The
first line in each set of three is runtime data. The other two lines are
derived from the ELF file. It's quite nice.

Comment 5

[tenthumbs]

Attachment: my_dladdr.c

Here's a version of my_dladdr that uses documented features.