[Mesa-dev] RFC: Memory allocation on Mesa

[Jose Fonseca]

________________________________
From: Timur Kristóf <timur.kristof at gmail.com>
Sent: Monday, May 11, 2020 18:06
To: Jose Fonseca <jfonseca at vmware.com>; ML mesa-dev <mesa-dev at lists.freedesktop.org>
Cc: erik.faye-lund at collabora.com <erik.faye-lund at collabora.com>
Subject: Re: [Mesa-dev] RFC: Memory allocation on Mesa

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.

Wouldn't you face the same issue if you chose to wrap all calls to
malloc and free in mesa, instead of relying on the linker? Any
dynamically linked or 3rd party library, including the C++ standard
library, will have no way of knowing about our wrapped malloc and free.

Timur

Indeed 3rd part libraries aren't tracked either way.   But I wasn't talking about 3rd party libraries, but rather Mesa itself.

Mesa is mostly written in C but some C++ code (ever more in fact.)  My point is that even if we ignore 3rd party libraries, if one takes the linker approach without statically linking, mesa new/delete calls would go unbalanced and the consequence would be crashes.

With explicit malloc/free, the consequent at most is untracked mallocs/frees, but there should never be any unbalanced mallocs frees, hence no crashes.

To be clear, there are two kinds of problems here:
1. allocate memory with one allocator and free with another -- this is catastrophic and will lead to a segfault
2. not intercept every single malloc/free pair -- this is not ideal -- but is inescapable to some extent .  One always need some memory reservation to plain old malloc/free, but the less the better.

Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20200512/3510f4ad/attachment-0001.htm>