(Context: a thread about OpenSSL's custom malloc wrapper on a non-public mailing list; I'm only quoting bits that are explicitly non-private, which is why this mail might seem rather disjointed)
Steinar H. Gunderson wrote: >> No malloc() sends a syscall for every malloc()/free(), except for >> big allocations. They all allocate larger chunks and carve out from >> them. >> >> Of course, some malloc()s do a poor job nevertheless, and there's >> also things >> like arena allocators which need to augment malloc() simply because >> the entire pattern is so different. and Angus Lees replied: > Indeed, valgrind intercepts the malloc/free/new/delete _library_ calls > since these (often) don't turn into syscalls. I presume valgrind can > be taught to treat other custom-arena functions in the same way, but I > haven't looked that closely at the valgrind docs. > > (Custom allocators / arenas are quite common for some valid > performance reasons - particularly for repeated allocations of the > same size. A witch hunt to track down every such example and waggle > a disapproving finger at it won't be useful) valgrind can certainly be taught to treat custom malloc wrappers like a plain malloc, by using its memcheck.h and valgrind.h headers. libdbus uses a memory pool for DBusList (linked list) links (and possibly a couple of other small structures) for exactly the reasons Angus describes. I taught valgrind about it in commits <http://cgit.freedesktop.org/dbus/dbus/commit/?id=b3f2ee5c6bade555630e52b8aa18fd639e047a80> and <http://cgit.freedesktop.org/dbus/dbus/commit/?id=01e3c41d75c1b31f0d2fac972b3ea2723dbde06e>. <http://cgit.freedesktop.org/dbus/dbus/commit/?id=13c1292150c4f5d57527d11f5b92f5b955f9906e>, <http://cgit.freedesktop.org/dbus/dbus/commit/?id=e516a31f59abbbf7cbfcc3396ef41162188a7f5c>, <http://cgit.freedesktop.org/dbus/dbus/commit/?id=57dc720b9f25dec999fcc53da982114098cefae9> are useful follow-ups if you're doing something similar. GLib also has a memory-pool subsystem (g_slice_new() and friends) which can be configured as a trivial pass-through to malloc() via G_SLICE=always-malloc in the environment. I believe recent GLib versions also support the same sort of valgrind instrumentation as libdbus. For cryptographic code, there are various extras that can be considered, particularly if you don't care too much about portability; gnome-keyring has a "secure memory" subsystem which uses mlock() and explicit zeroing, which seems like a useful thing for private keys. I think GNUTLS has something similar. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5370b054.10...@debian.org
