Valgrind doesn't report allocations with jemalloc on nightly

[apasel422]

Compiling the following code with opt-level=0, Valgrind reports 26 allocs for rustc 1.2.0 (082e47636 2015-08-03), but 5 allocs for rustc 1.4.0-nightly (cd138dc44 2015-09-02):

fn main() {
    let mut t = 0;

    for i in 0..10 {
        t += *Box::new(i);
    }

    assert_eq!(t, 45);
}

Perhaps this has something to do with #27400? In any case, it's harder to use Valgrind to debug Rust programs because of this.

[alexcrichton]

This is actually an optimization that LLVM is doing, it realizes that the allocation isn't necessary so it's elided entirely. As a result I believe this is working as intended, so closing.

[apasel422]

I'm not sure that's the case. Consider this program:

#![feature(test)]

extern crate test;

fn main() {
    for i in 0..100 {
        let foo = Box::new(i);
        test::black_box(foo);
    }
}

The assembly clearly contains calls to exchange_malloc, and running the code under gdb indicates that exchange_malloc is called 100 times:

(gdb) break _ZN4heap15exchange_malloc20he8623aa1084055ffJfaE
Breakpoint 1 at 0x4a90: file ../src/liballoc/heap.rs, line 123.
(gdb) ignore 1 1000
Will ignore next 1000 crossings of breakpoint 1.
(gdb) run
Starting program: /home/andrew/foo 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Inferior 1 (process 1890) exited normally]
(gdb) info breakpoints
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x0000555555558a90 in foo::heap::exchange_malloc at ../src/liballoc/heap.rs:123
    breakpoint already hit 100 times
    ignore next 900 hits

[apasel422]

But Valgrind reports:

==1899== Memcheck, a memory error detector
==1899== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1899== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==1899== Command: ./foo
==1899== 
==1899== 
==1899== HEAP SUMMARY:
==1899==     in use at exit: 0 bytes in 0 blocks
==1899==   total heap usage: 5 allocs, 5 frees, 976 bytes allocated
==1899== 
==1899== All heap blocks were freed -- no leaks are possible
==1899== 
==1899== For counts of detected and suppressed errors, rerun with: -v
==1899== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[alexcrichton]

Hm something fishy may indeed be going on here, it looks like valgrind is no longer tracking jemalloc? If you use alloc_system for now you'll get accurate tracking via valgrind, I'll reopen for more investigation into jemalloc though.

(also tweaking the title a bit)

[apasel422]

Using alloc_system indeed causes valgrind to report the correct information.

[shepmaster]

Sorry to jump in here, but how did you ever get valgrind to report jemalloc stats in the first place? On OS X, I've never successfully gotten any useful stats.

[apasel422]

I think the issue is that Valgrind can't track calls to jemalloc's mallocx-family of functions. There is a way to get Valgrind to track them, but it involves some custom headers: http://valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools

[apasel422]

See also https://github.com/jemalloc/jemalloc/blob/master/include/jemalloc/internal/valgrind.h.

[apasel422]

jemalloc is apparently not being built with --enable-valgrind (which makes sense for performance reasons):

foo.c:

#include <stdio.h>
#include <stdlib.h>

extern void je_mallctl(const char *, void *, size_t *, void *, size_t);

int main() {
    int valgrind = 6;
    size_t len = 1;
    je_mallctl("config.valgrind", &valgrind, &len, NULL, 0);
    printf("%d\n", valgrind);
}

> gcc foo.c -L/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/ -l:liballoc_jemalloc-35017696.rlib -lpthread
> ./a.out 
0

[apasel422]

Building nightly with

JEMALLOC_FLAGS='--enable-valgrind' make

results in the correct Valgrind behavior.

Not sure how we want to address this, but providing multiple versions of liballoc_jemalloc seems like a possibility.

[shepmaster]

FWIW, I ran your example program with rustc 1.5.0-dev (5f06607e2 2015-09-29) and valgrind-3.11.0.SVN on OS X, and it seems to track allocations:

==28285== HEAP SUMMARY:
==28285==     in use at exit: 35,221 bytes in 426 blocks
==28285==   total heap usage: 611 allocs, 185 frees, 42,405 bytes allocated

To my knowledge, I have not specified any custom flags when building. I also see that massif reports heap allocations over time, so I have some hope that things are just magically working together now!

[apasel422]

Valgrind on Ubuntu still indicates that this code, compiled with opt-level=0 on nightly, has only 5 allocations:

#![feature(alloc_jemalloc)]
#![feature(test)]

extern crate alloc_jemalloc;
extern crate test;

fn main() {
    for i in 0..100 {
        let foo = Box::new(i);
        test::black_box(foo);
    }
}

Removing the allocator has the same effect, while changing to alloc_system reports 112 allocations.