proc_macro::__internal::with_parse_sess() called before set_parse_sess()

[dtolnay]

serde-rs/serde#764 and alacritty/alacritty#413 both have this assertion failing. Is this a bug in rustc or in our use of libproc_macro?

pub fn with_parse_sess<F, R>(f: F) -> R
    where F: FnOnce(&ParseSess) -> R
{
    let p = CURRENT_SESS.with(|p| p.get());
    assert!(!p.is_null());
    f(unsafe { &*p })
}

cc @abonander and @alexcrichton who own most of that file
cc @jwilm who is debugging alacritty/alacritty#413

[abonander]

Something changed since I touched this file. I added a message to that assert!() when I implemented #[proc_macro_attribute].

[dtolnay]

Your message is in 1.16.0-beta. The panic is from 1.15.1. Any idea how this assert could be failing?

[abonander]

I'd have to look at the sources that Homebrew Rust used, apparently.

[alexcrichton]

This doesn't sound like a bug with either serde or the compiler but rather an error in some form of a binary artifact. At first blush this looks like the compiler is running with one libproc_macro.dylib but serde's using a different one. Basically libproc_macro.dylib relies on global state (the thread local) and if that's duplicate (in the case that there's two by accident) then things can go very wrong!

I'm installing Homebrew rust to investigate what's going on.

[alexcrichton]

Ah yes, that is indeed the bug. Here's what's happening.

So when you install Rust you actually get two copies of libraries. For example you'll have both:

• $sysroot/lib/libproc_macro-$hash.dylib
• $sysroot/lib/rustlib/x86_64-apple-darwin/lib/libproc_macro-$hash.dylib

Both of these should be byte-for-byte identical, we actually copy them in the build system! When you link against a dynamic library on OSX the library itself encodes a name of how to find it in the future by default. We can inspect this for rustup via the LC_ID_DYLIB attribute like so:

$ otool -l $sysroot/rustlib/x86_64-apple-darwin/lib/libproc_macro-*.dylib | grep -A2 LC_ID_DYLIB
          cmd LC_ID_DYLIB
      cmdsize 72
         name @rpath/libproc_macro-4a4250f8567d2c62.dylib (offset 24)

What this says is basically "in the future, find my by looking at @rpath (a meta variable) and look for this file name". If we take a look at Homebrew, however, we see a difference:

$ otool -l $sysroot/rustlib/x86_64-apple-darwin/lib/libproc_macro-*.dylib | grep -A2 LC_ID_DYLIB
          cmd LC_ID_DYLIB
      cmdsize 120
         name /usr/local/opt/rust/lib/rustlib/x86_64-apple-darwin/lib/libproc_macro-d8fca079e2c66403.dylib (offset 24)

Aha, a difference! I believe this is something that homebrew does by default, changing the value of LC_ID_DYLIB of installed dylibs (to ensure these versions are loaded, not others).

This change in LC_ID_DYLIB is then reflected in the libserde_derve-*.dylib itself, if we take a look at that we'll see for rustup:

          cmd LC_LOAD_DYLIB
      cmdsize 72
         name @rpath/libproc_macro-4a4250f8567d2c62.dylib (offset 24)

whereas for Homebrew we'll see:

          cmd LC_LOAD_DYLIB
      cmdsize 120
         name /usr/local/opt/rust/lib/rustlib/x86_64-apple-darwin/lib/libproc_macro-d8fca079e2c66403.dylib (offset 24)

So I think there's two bugs here:

1. There's a longstanding bug that we shouldn't ship duplicate sets of libraries, and this is something that we should sort out ourselves.
2. Homebrew may wish to not alter the LC_ID_DYLIB value of target libraries in $sysroot/lib/rustlib/*

[alexcrichton]

cc #28640, more info about the internals here

[brson]

Would this setup without rpath would work correctly if the homebrew build maintained the property that the two libs directories are identical? (It doesn't seem proper to require rpath for rust to work correctly).

[brson]

Excellent investigation @alexcrichton. Thanks.

[alexcrichton]

cc @ilovezfs and @alex, I've seen you two updating the Rust formula over at Homebrew/homebrew-core so I was hoping you'd be able to help me with a question.

In my comment above I've noticed that a Homebrew-installed version of Rust (specifically installed from a bottle) has a different LC_ID_DYLIB directive than the compiler is expecting, which is causing this problem unfortunately. I think this definitely a bug on our end that we could fix (to make this not actually cause problems) but that may take us awhile to fix so I was hoping we could in parallel pursue a solution with Homebrew as well.

Do you know if it's correct if Homebrew uses install_name_tool to alter dynamic libraries that are installed? I vaguely remember this being the case awhile back but poking around the codebase I can't seem to find any relevant locations. If not, do you know where such a change might arise?

I'm currently installing from source to verify it's not a bottle problem, but that may take a few minutes!

[alex]

Unfortunately I can't really help. I'm an unsophisticated person who just increments version numbers and computes hashes.

[ilovezfs]

@alexcrichton it's actually ruby-macho not install_name_tool, but yes you have the right idea about what's happening. Some manual interventions are also possible (see Homebrew/homebrew-core#8049 for examples).

The main reason the paths get changed is so that they use the opt path instead of the Cellar path, which prevents revision bumps from causing the paths to change, and thus all reverse dependencies to require pointless rebuilds even when there's been no change to the ABI.

It might be possible to fix the breakage in post_install, which runs after the bottle is poured but before brew install exits.

CC @woodruffw who knows the most about our use of ruby-macho for thoughts here.

[alexcrichton]

Ok cool, thanks for the info @ilovezfs! I think here what should happen is that libraries the rustc binary itself runs with should be changed as usual (e.g. what's happening today). The libraries installed that programs link against, however, should probably preserve the same LC_ID_DYLIB that Rust ships with, and I believe that'd fix this bug.

If I can finagle that locally does that sounds like a reasonable patch?

[ilovezfs]

If I can finagle that locally does that sounds like a reasonable patch?

Whatever actually works should be fine at least temporarily, but it would be good to get the fixes into rust or https://github.com/Homebrew/brew or some combination both if possible since manual uses of ruby-macho in homebrew/core are pretty yuck.

[ilovezfs]

BTW the magic mostly happens here: https://github.com/Homebrew/brew/blob/master/Library/Homebrew/extend/os/mac/keg_relocate.rb

[jwilm]

Fantastic work figuring this out @alexcrichton, and thanks @dtolnay for posting the issue.