Per-thread panic hooks

[nia-e]

Per-thread panic hooks

Problem statement

Arbitrary panic hooks are borderline incompatible with unsafe code due to them being safe to set & call, thus in theory forcing unsafe implementors to either never trigger a panic, even if caught (which involves linker hacks to prove in the general case), or to ignore this.

Setting & unsetting a panic hook by hand before & after an unsafe block is not a fix for this either, since the panic hook is set globally and another thread may safely unset it.

Motivating examples or use cases

Since global panic hooks are safe to set and unset, they may be able to access global state that libraries expose in a reentrant manner. This on its own is harmless, but libraries may soundly break their own safety invariants so long as they ensure such invariants are restored before calls into them return. Taken together, it is possible for a call into a library to panic internally before relevant global state is corrected, allowing a call into the same library from within the hook to observe these broken invariants. Setting a scoped panic hook would prevent this, as it would enable the hook setter to control what is run at the moment of panic and - crucially - ensure an unstrusted global hook is not run.

As setting such a hook is safe, setters cannot rely on hook behaviour when calling arbitrary untrusted code, but may do so to ensure that otherwise-trusted code does not have unintended behaviour on panic (e.g. an untrusted panic hook being invoked because of an erroring arithmetic operation).

Solution sketch

pub fn with_hook<'scope, F, T>(hook_fn: F, f: impl FnOnce() -> T + 'scope) -> T
where
    F: Fn(Option<&(dyn Fn(&PanicHookInfo<'_>) + 'scope)>, &PanicHookInfo<'_>)
        + 'scope,
    T: 'scope,

This function would then update a thread-local static hook which, if missing, forwards to the global hook.

Alternatives

N.B.: This was previously (2026-08-13) listed as the solution sketch.

Mirror panic::{set, take, update}_hook, without Send + Sync bounds:

// in std::panic

fn set_thread_hook(hook: Box<dyn Fn(&PanicHookInfo<'_>) + 'static>)

fn take_thread_hook() -> Box<dyn Fn(&PanicHookInfo<'_>) + 'static>

fn update_thread_hook<F>(hook_fn: F)
where
    F: Fn(&(dyn Fn(&PanicHookInfo<'_>) + 'static), &PanicHookInfo<'_>) + 'static

The main API alternative that comes to mind would be of the form

fn with_hook<T>(hook: Box<dyn Fn(&PanicHookInfo<'_>) + 'static>, f: impl FnOnce() -> T) -> T

where the closure f is invoked with hook as the panic hook. I could imagine this coexisting with the above proposal (it is a strictly weaker form of it and would be implementable in its terms), and has the advantage that the panic hook cannot thus altered for a function's caller as well; I'm unsure if this would be a desirable feature due to the better encapsulation of behaviour or a negative since it makes setting up relevant thread-global state harder. Some expressivity could be gained by relaxing the 'static bound on the hook here, which would require unsafe code to express with the current proposal (but would still be doable). I would also be happy saying we as std offer both.

Another option would be the status quo, since it's not the case that the panic hook is widely used in unsound ways.

Unresolved questions

What should the behaviour of newly-spawned threads be when a thread hook is set? Should it be copied from the spawning thread or default to none?

Should these be unsafe fns so unsafe code may rely on the hook being "correct" within a scope?

• Per discussion: No, reasoning about safety invariants in panic hooks is probably not the right approach and comes with a large amount of cognitive complexity

Links and related work

The conversation on the lang zulip re: handle_alloc_error possibly panicking and my past suggestion to make handle_alloc_error always abort.

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[programmerjake]

I definitely agree with also having the with_* variant. it makes code where you want everything in a scope to be covered that much easier since you don't need a drop guard

[tgross35]

For the alternative, the callback and function itself should probably return a T right?

This is lang scope but it would also be nice if we had a call_with_abort!(|| ...); that avoids needing to write an extern function.

[nia-e]

I'm also thinking about how we could prevent downstream code from overriding the hook, e.g. in the case of nested calls of with_hook; do they use update_hook semantics? replace it entirely? have with_hook return a result & error if a panic hook is already set?

there's quite a bit of design space to consider here and I'm uncertain what the right option is ^^ thus the ACP

[bushrat011899]

I'm also thinking about how we could prevent downstream code from overriding the hook, e.g. in the case of nested calls of with_hook; do they use update_hook semantics? replace it entirely? have with_hook return a result & error if a panic hook is already set?

If the goal is specifically to ensure unsafe code can have a deterministic panic hooo, what if instead the standard library provided with_default_hook? Nested calls would be no-ops since it's already been set to the default. Still might be useful to have thread-local panic hooks, but this seems like a good narrow solution to the unsafe panic part specifically.

[programmerjake]

I'm also thinking about how we could prevent downstream code from overriding the hook, e.g. in the case of nested calls of with_hook

I expect nested calls to replace the hook on scope entry and restore the saved hook on scope exit. I see no reason to prevent downstream from temporarily overriding the hook, if you're calling user code that could override the hook, it could also just as easily perform whatever bad actions the hook would do but directly.

maybe it would be good to have permanently overriding the hook without restoring the hook be unsafe:
e.g.:

pub fn f() {
    with_hook(safe_hook, || {
        depend_on_having_safe_hook();
        user_code();
        depend_on_having_safe_hook();
    })
}

fn user_code() {
    with_hook(bad, || ...); // fine since the safe hook gets restored
    set_thread_hook(bad); // not fine, so we probably shouldn't have `set_thread_hook` be a safe function
}

[programmerjake]

a response to my proposal

[programmerjake]

from the zulip thread some of us seem to want an API like:

#[derive(Copy, Clone)]
pub struct ScopedPanicHookInfo<'a> {}

impl<'a> ScopedPanicHookInfo<'a> {
    pub fn call_next_hook(self);
    pub fn panic_info(self) -> &'a PanicHookInfo<'a>;
}
pub fn with_hook<R>(hook: &dyn Fn(ScopedPanicHookInfo<'_>) + Sync, f: impl FnOnce() -> R) -> R;
pub fn get_scoped_hook<R>(f: impl FnOnce(&dyn Fn(ScopedPanicHookInfo<'_>) + Sync) -> R) -> R;

and Sync is so scoped threads can copy the hook

[tgross35]

If having a specific hook is required for safety, maybe something token-based like critical_section does could work? Not sure how that would interact with reentrancy, though.

[programmerjake]

for safe with_hook, we determined you can't depend on having any particular hook set for safety when calling user code, though you can for calling trusted libraries that may panic, like std.

https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/scoping.20panic.20hooks/near/613752456
in the context of hooks stack so you're guaranteed all with_hook hooks are called:

if you have with_hook(bad, || with_hook(fix_invariant, || { let v = break_invariant_and_fix_on_drop(); with_hook(bad, || panic!())))
seems like either order [of calling hooks in the stack] would let you get bad code in before fixing the invariant
so, imo the real fix is: don't call user code with observably broken invariants

[nia-e]

Per discussion above, my updated proposal:

// in std::panic
pub fn with_hook<'scope, F, T>(hook_fn: F, f: impl FnOnce() -> T + 'scope) -> T
where
    F: Fn(Option<&(dyn Fn(&PanicHookInfo<'_>) + 'scope)>, &PanicHookInfo<'_>)
        + 'scope,
    T: 'scope,

where hook gets the panic info and a handle to the "previous" panic hook set in the thread hook, or the global hook if none. since this would be safe to call and callers may ignore the handle to the previous hook, this couldn't be relied upon to restore invariants when calling entirely untrusted code, but i Think that's okay.

[programmerjake]

Nice, sounds good, though that needs some syntax checking.

[Noratrieb]

I don't think this is really the best approach. You lay out two major uses for this:

• using this to abort on panic
• using this to replace an unknown potentially dangerous panic hook with an known safe one during a critical section

I don't feel like panic hooks are the right approach to problem 1. To me, panic hooks feel like "high level" feature, which is especially shown by them being in std and not alloc. I see than as a tool to print fancy errors for programs, not as soundness critical low level tools.
And of course they're not in core. I think a much better approach for this problem would be to have something like core::panic::abort_on_unwind(|| panic!("this will about the process") that doesn't change any global state but instead just does the same as an extern "C" function, have the unwind action terminate and abort the process when something unwinds through it (and not when the panic is caught internally in the closure).

This global state can be confusing and I don't like the idea of making whether catch_unwind(|| panic!()) aborts context-dependent (other than the global panic strategy obviously).

That said, I do get the use case of worrying about a panic hook accessing global state in an unfortunate way. I would be fine with adding this explicitly for this use case and nothing else, and adding the better function for use case 1.

[Noratrieb]

Also I think it would be good to clarify the motivating examples and use cases a bit more. "Threads should be able to locally override the panic hook to facilitate restricting its behaviour" is obviously not a mptiviatinh example or a use case but just restating the proposal. The rest is very general which makes it hard for me to imagine what we're actually talking about.