You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
unlike libtcmalloc which comes with its own memory allocator, thelibmprofile uses CRYPTO_set_mem_functions(3ossl) to override CRYPTO_malloc(), CRYPTO_realloc() and CRYPTO_free() used in OpenSSL. After creating a profiling record the libmprofile dispatches the call further to libc to allocate/free memory. The libmprofile is not suitable for profiling long-time running processes because of massive overhead to keep profiling data. The libmprofile saves data to file when application exits. Those records are kept in heap memory allocated by libc.
The libmprofile currently lives here: https://github.com/sashan/mprofile. There is also pull request which adds libmprofile to openssl's make test: openssl/openssl#27139 Because the library uses CRYPTO_set_mem_functions(3ossl) we must also deal with static versions of libcrypto/libssl which both are used by many test tools. The preliminary plan is to make libmprofile part of libtestutil so the tests which use static libcrypto/libssl find libmprofile in libtestutil. This way we minimize the change to existing sources/build infrastructure. However it's not ideal the proper way is to make sure the test which use static libcrypto/libssl link with static version of libmprofile. The tests which use dynamic version of libcrypto/libssl should rely on LD_PRELOAD like we do for libtcmalloc (#1148). The current way in PR is less than ideal because test binaries which link dynamically with libcrypto/libssl get two copies of libmprofile: once comes via LD_PRELOAD, the other via libtestutil.
By default libmprofile just calculates max memory use by libcrypto/libssl in profiled application. This comes with zero memory overhead. It is safe to use for any process. The report is written when profiled application exits. The current .json form reads as follows:
Building libmprofile should be straigtforward. Its Makefile assumes gcc tools. Editing the makefile and commentin/uncommenting lines it can be adjusted to clang. The call stack collection is facilitated by libraries which come with compiler. To profile simple application which does OPENSSL_malloc() followed by OPENSSL_free() one does:
unlike libtcmalloc which comes with its own memory allocator, the
libmprofile
usesCRYPTO_set_mem_functions(3ossl)
to overrideCRYPTO_malloc()
,CRYPTO_realloc()
andCRYPTO_free()
used inOpenSSL
. After creating a profiling record the libmprofile dispatches the call further tolibc
to allocate/free memory. Thelibmprofile
is not suitable for profiling long-time running processes because of massive overhead to keep profiling data. Thelibmprofile
saves data to file when application exits. Those records are kept in heap memory allocated by libc.The libmprofile currently lives here: https://github.com/sashan/mprofile. There is also pull request which adds libmprofile to openssl's
make test
: openssl/openssl#27139 Because the library usesCRYPTO_set_mem_functions(3ossl)
we must also deal with static versions oflibcrypto
/libssl
which both are used by many test tools. The preliminary plan is to make libmprofile part of libtestutil so the tests which use static libcrypto/libssl find libmprofile in libtestutil. This way we minimize the change to existing sources/build infrastructure. However it's not ideal the proper way is to make sure the test which use static libcrypto/libssl link with static version of libmprofile. The tests which use dynamic version of libcrypto/libssl should rely onLD_PRELOAD
like we do for libtcmalloc (#1148). The current way in PR is less than ideal because test binaries which link dynamically with libcrypto/libssl get two copies of libmprofile: once comes via LD_PRELOAD, the other via libtestutil.By default libmprofile just calculates max memory use by libcrypto/libssl in profiled application. This comes with zero memory overhead. It is safe to use for any process. The report is written when profiled application exits. The current .json form reads as follows:
To obtain data above one can run
lhash_test
as follows:Building
libmprofile
should be straigtforward. ItsMakefile
assumesgcc
tools. Editing the makefile and commentin/uncommenting lines it can be adjusted to clang. The call stack collection is facilitated by libraries which come with compiler. To profile simple application which doesOPENSSL_malloc()
followed byOPENSSL_free()
one does:the
main.json
file then reads as follows:The magic
MPROFILE_MODE
is eplained in READMEThe text was updated successfully, but these errors were encountered: