[Mesa-dev] RFC: Memory allocation on Mesa

[Tamminen, Eero T]

Hi,

On Mon, 2020-05-11 at 16:13 +0000, Jose Fonseca wrote:
> Some might retort: why not just play some tricks with the linker, and
> intercept all malloc/free calls, without actually having to modify
> any source code?
> 
> Yes, that's indeed technically feasible.  And is precisely the sort
> of trick I was planing to resort to satisfy VMware needs without
> having to further modify the source code.  But for these tricks to
> work, it is absolutely imperative that one statically links C++
> library and STL.  The problem being that if one doesn't then there's
> an imbalance: the malloc/free/new/delete calls done in inline code on
> C++ headers will be intercepted, where as malloc/free/new/delete
> calls done in code from the shared object which is not inlined will
> not, causing havoc.  This is OK for us VMware (we do it already for
> many other reasons, including avoiding DLL hell.)  But I doubt it
> will be palatable for everybody else, particularly Linux distros, to
> have everything statically linked.

Huh?

I've done a lot of resource usage analysis at former job[1], but I've
never had needed anything like that.  malloc etc all reside in a
separate shared library from Mesa, so calls to them always cross
dynamic library boundary and therefore all of them can be caught with
the dynamic linker features (LD_PRELOAD, LD_AUDIT...).

Could you be confusing this with trying to catch some Mesa specific
function, where dynamic linker can catch only calls from application to
Mesa, but not calls within Mesa library itself (as they don't cross
dynamic library boundary)?

Note: at least earlier, new & delete typically called malloc & free (in
addition to calling ctor & dtor), in which case you don't even need to
track them separately.  You see their usage directly from the
allocation callgraph.


	- Eero

PS. Your XDot tool was a really nice tool for viewing those call-
graphs. :-)


[1] Linux has several ready-made tools for tracking resource
allocations (several Valgrind tools, ElectricFence, Duma etc), and we
added few more at Nokia, with main one being:
https://github.com/maemo-tools-old/sp-rtrace

(Most memorable thing was early Qt/C++ application version doing
~100000(!) allocation frees while it was initializing itself, due to
redundantly creating, localizing and removing one user view.)