Panic inside panic when procedural macro is called with proc_macro::bridge::client

[fedochet]

I am experiencing a strange panic that happens inside procedural macros when they are compiled as dynamic libraries, dynamically linked and then called explicitly using proc_macro::bridge::client.

It's quite hard to reproduce in small amount of code, so I've made up an example project where you can launch the tests and see the panic, it is here. Specifically, the stack backtrace can be seen here.

I've experimented with different compiler versions, and it seems that the only thing that triggers such panic is version alignment between compiler that compiled procedural macro itself, and compiler that compiled the code that is calling run method. As long as those compilers have different versions, everything works as expected.

I wasn't able to find the reason of this problem myself, so I thought it may be useful for you to know about this behaviour (maybe it is a bug of some sort).

[eddyb]

First off, you have both of these in the stack trace:

• src/libproc_macro/bridge/client.rs
• /rustc/a3404557c54ea48fb8efc805d93c450beb3364d4/src/libproc_macro/bridge/server.rs

Did you build the former yourself? If not, how come it doesn't have the hash in it?
To be clear, you need that source to be from a340455, and the build settings to match the upstream, otherwise it won't be compatible.

I'm suspecting you have a libproc_macro laying around from 597f432 (which is the other hash).
Or maybe I can't trust the paths, so this doesn't mean anything.

---

One thing you could try is to have a proc macro crate as a dependency of your project, which will ensure it gets compiled with the same compiler and against the same libproc_macro, and then you can search in target/debug/deps for the .so.

---

Proc macros presumably work on nightly, and officially your usecase is not supported, so I can't spend a lot of time looking into it, sorry, but I'll try to when I can.

[fedochet]

@eddyb thanks for your time and efforts!

If I understand your question correctly, then no, I did not build client.rs myself, or at least I think so. I've used a stock nightly compiler, not locally compiled

However, I'm using #![feature(proc_macro_internals)] to be able to use extern crate proc_macro and its internals. Maybe this is what actually triggers compilation of this module, and this is why there are different paths in the stack trace (probably, part of it is from code that I've compiled, and part of it is from already compiled code that is used in procedural macro)

I don't get the part about making proc_macro a dependency. I wasn't able to add it to the Cargo.toml, or locate it on the crates.io. Can you please explain what did you mean?

[eddyb]

Not proc_macro the crate, but the proc macro crate you are building during the test, you can have it in the same repository, and use a path dependency, instead of creating it in a temporary directory.

[fedochet]

I've tried to do that, unfortunately with no luck

I've updated the repo with test that uses path dependency (you should cargo clean everything after test so there are no chance that old compiled macro is used)

[eddyb]

@fedochet "no luck" as in "it still causes the panic"? Or does it work as intended in that configuration?

[fedochet]

@eddyb yes, still panic inside panic with same stacktrace

[eddyb]

Alright, so a potential reason for rustc not hitting this is always using a different copy of the library, but with a compatible ABI.
Still, I can't think of any reason sharing libproc_macro.rlib between the server and the client wouldn't work, they shouldn't have any global resources in common.

[edwin0cheng]

Just copy from the project issue i wrote:

After a little bit of digging, my guess is, it is not related to ABI compatible problem. It seem to be related to the different of thread_local storage of static linkage and dynamic linkage.

The actual panic is this line.
And state is actually a thread_local :

rust/src/libproc_macro/bridge/client.rs

Line 269 in dc6db14

static BRIDGE_STATE: scoped_cell::ScopedCell<BridgeStateL> =

On the other hand, in the example project:

https://github.com/fedochet/rust-proc-macro-panic-inside-panic-expample/blob/6ef3a6452c19ab6edab1829d048368ce811b07c3/src/main.rs#L164

client.run function will call Bridge::enter and set the state to BridgeState::Connected. Note that this is statically link to main crate.

And after that, when the actual TokenStream start to parse, Bridge::with will be called from shared library crate (which is dynamic link) and it will trigger the panic.

It seem to be two thread local are different, such that the panic get raised. But I don't know enough about linux shared library and thread local mechanism to understand this bug.

[eddyb]

@edwin0cheng Static vs dynamic linking does sound scary.
However, note that Bridge::enter is called from this function:

rust/src/libproc_macro/bridge/client.rs

Lines 341 to 351 in 7da1185

	// FIXME(#53451) public to work around `Cannot create local mono-item` ICE,
	// affecting not only the function itself, but also the `BridgeState` `thread_local!`.
	pub extern "C" fn __run_expand1(
	mut bridge: Bridge<'_>,
	f: fn(crate::TokenStream) -> crate::TokenStream,
	) -> Buffer<u8> {
	// The initial `cached_buffer` contains the input.
	let mut b = bridge.cached_buffer.take();
	panic::catch_unwind(panic::AssertUnwindSafe(|| {
	bridge.enter(|| {

Which is used as a fn pointer as part of the Client struct you get from the dylib.

To investigate further, you could transmute the Client, just before calling .run on it, to [*const (); 3], and print it (with {:?}), and also print proc_macro::bridge::client::__run_expand1 as *const () - if the latter is equal to the second (middle) element of the former array, then the dynamic loading of proc macro dylib picked up a statically linked fn (which would be bad if the TLS isn't also deduplicated).

[edwin0cheng]

@eddyb Thanks for the information, it helps a lot for me to understand how it works.

I seem to understand why this bug happens, would you mind to tell me does it make sense ?

I can confirmed that the thread_local i mentioned previously are different in Bridge::enter and Bridge::with (by inserting dbg! in rustc source code directly). And it is because Bridge::with use a wrong thread local coming from static linkage.

Why the static linkage is introduced ? Surprisingly it is introduced by syn crate we used to parse the input string to TokenStream. Seem like dynamic linker is "smart" enough to merge some code path from dynamic linkage to static linkage. And that's why it depends on how dynamic linker implementation.

But in rustc it doesn't use procmacro::TokenStream, it uses syntax::TokenStream directly :

rust/src/libsyntax_ext/proc_macro_impl.rs

Line 17 in 9ebf478

impl base::AttrProcMacro for AttrProcMacro {

use syntax::tokenstream::TokenStream;

// ....

impl base::AttrProcMacro for AttrProcMacro {
    fn expand<'cx>(&self,
                   ecx: &'cx mut ExtCtxt<'_>,
                   span: Span,
                   annotation: TokenStream,
                   annotated: TokenStream)
                   -> TokenStream {
        let server = proc_macro_server::Rustc::new(ecx);
        match self.client.run(&EXEC_STRATEGY, server, annotation, annotated) {
    // ....
}

And that's why in server.rs, it use a Server trait :

impl client::Client<fn(crate::TokenStream) -> crate::TokenStream> {
pub fn run<S: Server>(

So that it won't introduce the static linkage of thread_local in their code.

[eddyb]

There is a dynamic indirection between the Client::run and all the code that uses Bridge::{with,enter}. I don't think what you're saying is possible.

Can you do what I said? Print those transmuted pointers?
Without that information I don't see how we can do better than guess.

[edwin0cheng]

@eddyb Sure :

running 1 test
[
    0x00007fdd79d6b730,
    0x00007fdd79d6b290,
    0x00007fdd79d6a320,
]
0x00007fdd7bb6a7d8
[src/libproc_macro/bridge/client.rs:249] "$method" = "$method"
[src/libproc_macro/bridge/client.rs:319] p_with = 0x00007fdd7be330a0
[src/libproc_macro/bridge/client.rs:356] "__run_expand1" = "__run_expand1"
[src/libproc_macro/bridge/client.rs:295] p_enter = 0x00007fdd7a09fd00
[src/libproc_macro/bridge/client.rs:319] p_with = 0x00007fdd7a09fd00
[src/libproc_macro/bridge/client.rs:249] "$method" = "$method"
[src/libproc_macro/bridge/client.rs:319] p_with = 0x00007fdd7be330a0
thread 'test_getset_expansion' panicked at 'procedural macro API is used outside of a procedural macro', src/libproc_macro/bridge/client.rs:324:17
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /home/edwin/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.25/src/backtrace/libunwind.rs:97
   1: backtrace::backtrace::trace_unsynchronized
             at /home/edwin/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.25/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:47

The code I insert println which is in callsite of @fedochet test project:

   for proc_macro in *proc_macros {
        match proc_macro {
            ProcMacro::Bang { client, .. } => {
                unsafe {
                    let p1: &[*const (); 3] = std::mem::transmute(client);
                    let f = &proc_macro::bridge::client::__run_expand1;
                    println!("{:#?}", p1);
                    println!("{:#?}", f as *const _);
                }
                let result = client.run(
                    &EXEC_STRATEGY,
                    rustc_server::Rustc::default(),
                    parse_string("struct S{}").expect("Cannot parse code"),
                );

It is different. However, the other dbg! I insert in the rustc tell the different story. What i did is inserting dbg! in src/libproc_macro/bridge/client.rs:

impl Bridge<'_> {                                                                            
    fn enter<R>(self, f: impl FnOnce() -> R) -> R {                                          
       let p_enter = &BRIDGE_STATE as *const _;               // <-------------                               
        dbg!(p_enter);                                              // <-------------                               
                                                                                                                                                                                          
        // Hide the default panic output within `proc_macro` expansions.                     
        // NB. the server can't do this because it may use a different libstd.               
        static HIDE_PANICS_DURING_EXPANSION: Once = Once::new();                             
        HIDE_PANICS_DURING_EXPANSION.call_once(|| {                                          
            let prev = panic::take_hook();                                                   
            panic::set_hook(Box::new(move |info| {                                           
                let hide = BridgeState::with(|state| match state {                           
                    BridgeState::NotConnected => false,                                      
                    BridgeState::Connected(_) | BridgeState::InUse => true,                  
                });                                                                          
                if !hide {                                                                   
                    prev(info)                                                               
                }                                                                            
            }));                                                                             
        });                                                                                  
                                                                                             
        BRIDGE_STATE.with(|state| state.set(BridgeState::Connected(self), f))                
    }                                                                                        
                                                                                             
    fn with<R>(f: impl FnOnce(&mut Bridge<'_>) -> R) -> R {                                  
        let p_with = &BRIDGE_STATE as *const _;             // <-------------                                                                
        dbg!(p_with);                                                 // <-------------                                                 
                                                                                             
                                                                                             
        BridgeState::with(|state| match state {                                              
            BridgeState::NotConnected => {                                                   
                panic!("procedural macro API is used outside of a procedural macro");        
            }                                                                                
            BridgeState::InUse => {                                                          
                panic!("procedural macro API is used while it's already in use");            
            }                                                                                
            BridgeState::Connected(bridge) => f(bridge),                                     
        })                                                                                   
    }                                                                                        
}                                                                                            

[edwin0cheng]

@eddyb and @fedochet here is a minimal project which demonstrable the override effect.