Description
UPDATED REPORT
I decided to investigate what was happening and why anything was working at all today, and I found some surprising results. My investigation involved breaking on uv_fs_open and then seeing what happened. One of the first things that this function does is invoke strdup, which is then later deallocated with free. I followed these calls to figure out which malloc (part of strdup) and free were getting used. This data was all collected by running ./$platform/stage0/bin/rustc and just seeing what happened.
| platform | malloc | free | global_heap::malloc_raw |
global_heap::exchange_free |
|---|---|---|---|---|
| x86_64-unknown-linux | jemalloc | jemalloc | jemalloc | jemalloc |
| i686-unknown-linux | libc | jemalloc | libc | libc |
| x86_64-apple-darwin | libc | libc | ? | ? |
| i686-apple-darwin | libc | libc | ? | ? |
It appears that 32-bit linux is the worst off where the allocator is being mismatched, but I'm not certain that it's not being mismatched on other platforms.
ORIGINAL REPORT
I was stepping through i386 linux recently, and got this backtrace:
Breakpoint 8, __GI___libc_malloc (bytes=16) at malloc.c:2910
2910 malloc.c: No such file or directory.
(gdb) bt
#0 __GI___libc_malloc (bytes=16) at malloc.c:2910
#1 0xf7ac196f in rt::global_heap::malloc_raw::hbc5969e10a864a8a4::v0.9$x2dpre ()
from /home/alex/rust/x86_64-unknown-linux-gnu/stage1/lib/rustc/i686-unknown-linux-gnu/lib/libstd-6c65cf4b443341b1
-0.9-pre.so
#2 0xf7b6124e in rt::uv::uvio::EventLoop$UvEventLoop::remote_callback::h14d1de56cbaf539eaVaQ::v0.9$x2dpre ()
from /home/alex/rust/x86_64-unknown-linux-gnu/stage1/lib/rustc/i686-unknown-linux-gnu/lib/libstd-6c65cf4b443341b1
-0.9-pre.so
#3 0xf7b00d66 in rt::sched::Scheduler::make_handle::hfe732d5489154f1873aL::v0.9$x2dpre ()
from /home/alex/rust/x86_64-unknown-linux-gnu/stage1/lib/rustc/i686-unknown-linux-gnu/lib/libstd-6c65cf4b443341b1
-0.9-pre.so
#4 0xf7b5bae1 in rt::sched::Scheduler::run_sched_once::hf3525925b944a5173a8::v0.9$x2dpre ()
from /home/alex/rust/x86_64-unknown-linux-gnu/stage1/lib/rustc/i686-unknown-linux-gnu/lib/libstd-6c65cf4b443341b1
-0.9-pre.so
#5 0xf7b71896 in rt::uv::uvio::__extensions__::start::anon::expr_fn::aq ()
from /home/alex/rust/x86_64-unknown-linux-gnu/stage1/lib/rustc/i686-unknown-linux-gnu/lib/libstd-6c65cf4b443341b1
This appears to indicate that we are not using jemalloc for the exchange or managed heaps. I did see jemalloc get used by libuv though (but jemalloc is linked statically to libuv)