Repository navigation
Calling std::thread::current() in global allocator results in non-obvious error #115209
Description
Global allocator is a special piece of code because it runs before main(). Parts of standard library are not available at this time and it’s (as far as I know) not documented in safety contract of GlobalAlloc, or, for that matter, anywhere else.
It seems like some sort of a doc specifying which functions are “before-main-safe” (so can be used in GlobalAlloc and #[ctor]) would be really useful. On top of that, I think that identifying the current thread should be allowed in the global allocator.
I tried this code (playground):
use std::alloc::{GlobalAlloc, Layout, System};
struct MyGlobalAlloc;
unsafe impl GlobalAlloc for MyGlobalAlloc {
unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
std::panic::catch_unwind(|| std::thread::current()).ok();
System.alloc(layout)
}
unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout) {
System.dealloc(ptr, layout)
}
}
#[global_allocator]
static _ALLOCATOR: MyGlobalAlloc = MyGlobalAlloc;
fn main() {}I expected to see this happen: nothing at all, it should just work.
Instead, this happened:
thread panicked while processing panic. aborting.
I’ve also seen:
fatal runtime error: assertion failed: thread_info.is_none()
but I can’t reliably reproduce it.
Meta
rustc --version --verbose:
rustc 1.73.0-nightly (08d00b40a 2023-08-09)
binary: rustc
commit-hash: 08d00b40aef2017fe6dba3ff7d6476efa0c10888
commit-date: 2023-08-09
host: x86_64-unknown-linux-gnu
release: 1.73.0-nightly
LLVM version: 17.0.0
but it reproduces on stable, beta and nightly.
I’m not actually sure if this is a bug, but I think one of the following must be true:
- Either global allocator should be able to call
std::thread::current().id()without crashing the program, - or its inability to do so should be documented in docs for
GlobalAlloc,#[global_allocator], orstd::thread::current(), preferably all of them.
Activity
[-]Calling std::thread::current() in global allocator results in non-obvious error[/-][+]Calling `std::thread::current()` in global allocator results in non-obvious error[/+][-]Calling `std::thread::current()` in global allocator results in non-obvious error[/-][+]Calling `std::thread::current() in global allocator results in non-obvious error[/+][-]Calling `std::thread::current() in global allocator results in non-obvious error[/-][+]Calling `std::thread::current()` in global allocator results in non-obvious error[/+]asokol123 commentedon Aug 25, 2023
In macos result is always
[1] 99360 illegal hardware instruction cargo runMeta
rustc --version --verboseChrisDenton commentedon Aug 25, 2023
Pre-main behaviour was also discussed in #110708. The feeling was that in general we should endeavour to make as much of the std work as possible and document where it doesn't. The complicating factor is that this is highly platform specific and there are likely to always be caveats and shifting behaviour as implementations evolve.
But yes, documenting it is definitely worth doing if someone wants to help with that.
GoldsteinE commentedon Aug 25, 2023
I’d help with documenting, but I’m not sure where this should be documented. I’m also not sure whether it should be documented as “you can use these APIs pre-main” or “you can’t use these other APIs pre-main”.
A separate question is why
std::thread::current()is not pre-main-safe. Linked issue only talks about it being non-post-main-safe.asokol123 commentedon Aug 25, 2023
Also, this code hangs in macos, so maybe not related to pre-main:
If you remove
#[global_allocator]orthread::spawn, it works normallyrustc --version --verboseChrisDenton commentedon Aug 25, 2023
Oh hm, yeah it seems more likely that the issue is
std::thread::currentitself allocating.lolbinarycat commentedon Jul 15, 2024
it seems that it allocates because it uses
thread_local!, it's the same underlying issue as #116390joboet commentedon Oct 9, 2024
With #127912 merged, this now triggers an abort with a hopefully clearer message:
Auto merge of #144465 - orlp:system-alloc-tls, r=Mark-Simulacrum
Auto merge of #144465 - orlp:system-alloc-tls, r=joboet
Auto merge of #144465 - orlp:system-alloc-tls, r=Mark-Simulacrum
Auto merge of #144465 - orlp:system-alloc-tls, r=Mark-Simulacrum
Auto merge of #144465 - orlp:system-alloc-tls, r=Mark-Simulacrum
Auto merge of #144465 - orlp:system-alloc-tls, r=Mark-Simulacrum
Auto merge of #144465 - orlp:system-alloc-tls, r=Mark-Simulacrum
Auto merge of #144465 - orlp:system-alloc-tls, r=Mark-Simulacrum
Auto merge of rust-lang#144465 - orlp:system-alloc-tls, r=Mark-Simula…
Auto merge of #144465 - orlp:system-alloc-tls, r=Mark-Simulacrum