You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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 topthread_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 usepthread_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.
The text was updated successfully, but these errors were encountered: