From d98ab4faf869ff0430ad73260b13ef8e473ef212 Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Wed, 15 Apr 2015 12:27:05 -0700 Subject: std: Don't assume thread::current() works on panic Inspecting the current thread's info may not always work due to the TLS value having been destroyed (or is actively being destroyed). The code for printing a panic message assumed, however, that it could acquire the thread's name through this method. Instead this commit propagates the `Option` outwards to allow the `std::panicking` module to handle the case where the current thread isn't present. While it solves the immediate issue of #24313, there is still another underlying issue of panicking destructors in thread locals will abort the process. Closes #24313 --- src/libstd/thread/mod.rs | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'src/libstd/thread') diff --git a/src/libstd/thread/mod.rs b/src/libstd/thread/mod.rs index 383726b3e83..ce531fb1381 100644 --- a/src/libstd/thread/mod.rs +++ b/src/libstd/thread/mod.rs @@ -407,7 +407,9 @@ pub fn scoped<'a, T, F>(f: F) -> JoinGuard<'a, T> where /// Gets a handle to the thread that invokes it. #[stable(feature = "rust1", since = "1.0.0")] pub fn current() -> Thread { - thread_info::current_thread() + thread_info::current_thread().expect("use of std::thread::current() is not \ + possible after the thread's local \ + data has been destroyed") } /// Cooperatively gives up a timeslice to the OS scheduler. -- cgit 1.4.1-3-g733a5