search

nnethercote / dhat-rs

Heap profiling and ad hoc profiling for Rust programs.
Apache License 2.0
713 stars 36 forks source link

dhat-rs doesn't work on platforms where pthread_setspecific is used for TLS #31

Open worr opened 1 year ago

worr commented 1 year ago

Currently, dhat-rs uses TLS to store IGNORE_ALLOCS, which is used by the customer allocator. However, there are three different flavors of TLS implementation in Rust: static (the platform doesn't have threads, so this uses static global vars), fast (the one that Linux and macOS on x86_64 use) and os, which delegates the TLS management to pthread_setspecific.

The problem is that in the case where pthread_setspecific is used, Rust will allocate, which can then invoke the allocator. This causes failures on at least two platforms that I've tested (FreeBSD 13.2, OpenBSD 7.3 and -current) trying to call any code that uses dhat's custom allocator. There are more platforms affected by this (Illumos, maybe AArch64 macOS?, android, and more) based on how they also use pthread_setspecific, but I haven't tested.

You can see more details in the Rust source:

https://github.com/rust-lang/rust/blob/master/library/std/src/sys/common/thread_local/mod.rs The allocation in question: https://github.com/rust-lang/rust/blob/db4a1534402a163f9296347d31796f070ae7c4e1/library/std/src/sys/common/thread_local/os_local.rs#L145

I'm pretty sure the above is where the issue lies? I'm not really sure how best to resolve this, since the state of whether or not to track allocations needs to be shared between all of the different objects in the library, so it's not like the tracking of that can be made object-local.

nnethercote commented 7 months ago

This kind of problem is the bane of this kind of crate, unfortunately. I also don't know how to resolve this.