Unclear how to enable profiling #115
Comments
That's the expected output. |
|
Right, so something like this should be written to stdout? |
|
That's correct. |
|
By default jemalloc is built with a prefix, which I think the environment variable includes. |
After reading Do you mean that the runtime env var will also change if you use a prefix? Or only the one that's passed in when compiling in |
|
That output looks like it may be from rustc's own jemalloc. Try running your binary directly. |
|
Got it work, the trick is indeed to use |
|
One more thing I'm running into: the output is showing hex addresses and no readable names. Debug symbols are present. Maybe this is out of scope for this crate: But does anybody have pointers on how to get useful names? I'd love to find a way to make this easily usable and will submit a pull with at least some doc updates after I figure this out. |
|
We should definitely document this in I'm going to leave this issue open to track that. @thijsc which platform (target triple) are you on? |
|
I'm currently testing on Mac, but intend to run it on our staging environment that runs Linux as well. I feel like I'm getting pretty close to this working. Two things are still not:
I'm reading the jemalloc docs but haven't found hints on how to fix these two, debugging some more atm. |
|
Note that profiling is not supported on macos x: jemalloc/jemalloc#26 I'd guess we could be more proactive in jemallocator by failing to build, but there is a bug in jemalloc where enabling profiling does not fail to build on mac :/ |
|
On my Linux machine, I have profiling and such, but there are no symbol names, just as @thijsc is experiencing |
|
Well it does generate heap dump files, so some of it works at least. |
|
It might be interesting to find out whether this is a jemalloc-sys/jemallocator bug or a bug on jemalloc. Can you reproduce this using C ? |
|
I have managed to get the summary that @thijsc is looking for on my linux box with: This is for a tiny Rust project entirely to validate leak detection works: #[global_allocator]
static ALLOC: jemallocator::Jemalloc = jemallocator::Jemalloc;
use std::mem;
fn main() {
for i in 0..1_000_000i64 {
let b = Box::new("bla".to_owned());
mem::forget(b);
}
}This program gives me a heap file like: As we can see, the function addresses are just that, opaque addresses. If there's some C that we would like tested in a similar way, I'm happy to oblige. |
|
It looks like the unclean symbols may be more of a jemalloc issue, as using the one shipped with Ubuntu Cosmic (18.10) shows the same issue with this C program: #include <stdlib.h>
#include <string.h>
int main(int argc, char **argv)
{
int i;
for (i = 0; i < 1000000; i++) {
char *test = (char*) malloc(12*sizeof(char));
strcpy(test, "testingonly");
// free(test);
}
}As above, my heap file looks like: |
|
The above |
|
@ChrisMacNaughton are you running jemalloc's
|
|
I was using jemalloc's |
|
I think it would be best if you could fill your C example as a jemalloc issue, and cross-link it with this one. |
|
Interestingly, the heap file being unclear doesn't seem to translate to the C example being rough - attached is a PRF generated from jeprof that seems to actually list some names |
|
@ChrisMacNaughton interesting, can you check whether your jemalloc is being compiled with |
|
After adding: diff --git a/jemalloc-sys/build.rs b/jemalloc-sys/build.rs
index 3801619..efd2664 100644
--- a/jemalloc-sys/build.rs
+++ b/jemalloc-sys/build.rs
@@ -257,6 +257,7 @@ fn main() {
info!("--with-lg-vaddr={}", lg_vaddr);
cmd.arg(format!("--with-lg-vaddr={}", lg_vaddr));
}
+ cmd.arg("--enable-prof-libunwind");
let mut use_prefix =
env::var("CARGO_FEATURE_UNPREFIXED_MALLOC_ON_SUPPORTED_PLATFORMS").is_err();my generated PDF still doesn't have usable call sites: heap2.pdf |
|
Can you upload the output of a verbose build (showing jemalloc's configure) somewhere (e.g. a github gist) ? |
|
Also, I just discovered that you can find that output for any build in |
|
@ChrisMacNaughton so for some reason enabling libunwind did not work out properly in your case, e.g., see https://gist.github.com/ChrisMacNaughton/a4e3bcc87eecc5175bb12df6bcd477f4#file-jemalloc-sys-output-L113 and https://gist.github.com/ChrisMacNaughton/a4e3bcc87eecc5175bb12df6bcd477f4#file-jemalloc-sys-output-L241 This (https://gist.github.com/ChrisMacNaughton/a4e3bcc87eecc5175bb12df6bcd477f4#file-jemalloc-sys-output-L105) shows that
EDIT: It also might be worth checking whether the C example was using a jemalloc version that uses libunwind or not - it might be that there is an error in the |
|
so, cool stuff - on my local copy that asks for libunwind, after I install libunwind-dev I get a stacktrace on building - |
|
IIRC there were some linking errors with libunwind that were fixed upstream some time ago. I've just opened a PR with a branch that let's you |
|
well, slightly painful with your PR + my above diff: https://gist.github.com/ChrisMacNaughton/22dff39d5739ce1bd51b502ebeb17270 in essence: |
|
Here is a list of steps that worked for me on GNU/Linux: I hope future readers will find it useful. |
|
Note: make sure to check your executable directory is writeable (eg if you are running a systemd service, the working dir would be You can see output like This can be fixed using setting your envvar to be something like: The final created file would be like Make sure to also build your binary with debug symbols, for example adding this to [profile.release]
debug = trueView the graph with Make sure to run jeprof on the same system that the binary is built on, else you may get errors like this: |
I'm trying to get jemalloc to do heap profiling by configuring it in the environment:
export MALLOC_CONF=prof:true,lg_prof_interval:30,lg_prof_sample:17Profiling is enabled:
I do not see the expected output as described here. Is this expected to work when using this crate?
The text was updated successfully, but these errors were encountered: