This adds a mode argument to getmemoryinfo. By default the output will remain the same. However if a mode argument of mallocinfo is provided the result of glibc malloc_info (if available) will be returned as a string, as-is.
This output contains detailed malloc heap statistics, and is useful for tracking heap usage over time or troubleshooting memory fragmentation issues.
This adds a mode argument to `getmemoryinfo`. By default the output
will remain the same. However if a mode argument of `mallocinfo` is
provided the result of glibc `malloc_info` (if available) will
be returned as a string, as-is.
This is useful for tracking heap usage over time or troubleshooting
memory fragmentation issues.
542 | - return obj; 543 | + 544 | + std::string mode = (request.params.size() < 1 || request.params[0].isNull()) ? "stats" : request.params[0].get_str(); 545 | + if (mode == "stats") { 546 | + UniValue obj(UniValue::VOBJ); 547 | + obj.push_back(Pair("locked", RPCLockedMemoryInfo()));
Don't we need to escape this in some ways? Or is that handled by UniValue?
That's handled by UniValue. The whole object is returned as a JSON string. (UniValue has an implicit constructor from string).
As for the GLIBC 2.10 symbol requirement, the minimum version of glibc in our symbol checker is 2.11, so this is acceptable for binary releases: https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/symbol-check.py#L43
Nice. To bad there is no clang equivalent of malloc_info(). This will be linux only.
Tested ACK e141aa4ba604ff22c68454112501c166d3e892c9
https://bitcoin.jonasschnelli.ch/build/PR/10038
<img width="730" alt="bildschirmfoto 2017-03-20 um 12 12 06" src="https://cloud.githubusercontent.com/assets/178464/24097654/206cdb76-0d67-11e7-9668-d06fe13e5f27.png">
<img width="909" alt="bildschirmfoto 2017-03-20 um 12 16 54" src="https://cloud.githubusercontent.com/assets/178464/24097653/20440b92-0d67-11e7-911d-34cab74d6c70.png">
Nice. To bad there is no clang equivalent of malloc_info(). This will be linux only.
Clang on Linux simply uses glibc. But yeah, other libc's will either have equivalent calls or maybe not, it's specific to the malloc implementation.
Tested on OSX ACK e141aa4
postmerge ACK (was merged in the middle of my testing)
postmerge ACK (was merged in the middle of my testing)
Yeah sorry for that, getting this in soon is kind of important due to all the reported OOM issues with 0.14.
postumous utACK e141aa4ba604ff22c68454112501c166d3e892c9
Is there a reason not to just add it as an additional key in the result?
Is there a reason not to just add it as an additional key in the result?
I did that first, but having a huge encoded XML string field in the default JSON object output was ugly. Also this information is potentially slow to compile, so it's better to have it on an separate entry point.