Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dsymutil hits SIGBUS during cargo build, and spams warnings like "could not find object file symbol for symbol" #84849

Open
thomcc opened this issue May 3, 2021 · 0 comments
Labels
A-codegen Area: Code generation C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@thomcc
Copy link
Member

thomcc commented May 3, 2021

When building evcxr_repl on macOS (via, e.g. cargo build -p evcxr_repl), around the end of the build, I sometimes (often) get these warnings:

   Compiling evcxr v0.9.0 (/Users/thom/src/evcxr/evcxr)
   Compiling evcxr_repl v0.9.0 (/Users/thom/src/evcxr/evcxr_repl)
   Compiling evcxr_jupyter v0.9.0 (/Users/thom/src/evcxr/evcxr_jupyter)
   Compiling print_performance_info v0.1.0 (/Users/thom/src/evcxr/print_performance_info)
warning: processing debug info with `dsymutil` failed: signal: 10
  |
  = note: warning: (x86_64)  could not find object file symbol for symbol _anon.0badcb2317405270e2661460eadb52d3.13
          warning: (x86_64)  could not find object file symbol for symbol _anon.0badcb2317405270e2661460eadb52d3.14
          warning: (x86_64)  could not find object file symbol for symbol _anon.0badcb2317405270e2661460eadb52d3.22
          warning: (x86_64)  could not find object file symbol for symbol _anon.0badcb2317405270e2661460eadb52d3.56
          warning: (x86_64)  could not find object file symbol for symbol _anon.0badcb2317405270e2661460eadb52d3.57
          warning: (x86_64)  could not find object file symbol for symbol _anon.0badcb2317405270e2661460eadb52d3.58
          warning: (x86_64)  could not find object file symbol for symbol _anon.0badcb2317405270e2661460eadb52d3.59
          warning: (x86_64)  could not find object file symbol for symbol _anon.0badcb2317405270e2661460eadb52d3.60
.... snip ....

Not just _anon.$hash.$counter tho, in the output it also has a bunch of static vars and the like:

          warning: (x86_64)  could not find object file symbol for symbol _str.0
          warning: (x86_64)  could not find object file symbol for symbol __ZN4rand4rngs7adapter9reseeding4fork26RESEEDING_RNG_FORK_COUNTER17ha4496ddbf5daa60fE
          warning: (x86_64)  could not find object file symbol for symbol __ZN16parking_lot_core11parking_lot11NUM_THREADS17hf52042d8081b2715E
          warning: (x86_64)  could not find object file symbol for symbol __ZN4json6object4NULL17he3487848e2e9f694E

Anyway, this is abridged. It has about 6000 more lines with similar complaints. It doesn't cause the build to fail, but seems undesirable nonetheless. Presumably, debugging one of those builds wouldn't work (but I could be wrong, I haven't tried).


This pretty clearly has something to do with the split-debuginfo change, but I'm not sure what exactly it means.

I believe signal 10 is SIGBUS on macOS, which probably means dsymutil was trying to mmap some nonsense and something went wrong.

It cold also just be run of the mill memory corruption and such (ofc, something that could have been a SIGSEGV can always happen to show up as a SIGBUS), but... IME, SIGBUS is usually a symptom of mmap-gone-wrong.

Perhaps part of the rust build process modified one of the files it was reading or writing? Or rust-analyzer, as I had vscode open in the background... (No idea, although if I were forced to bet on what I thought the outcome was, I guess this seems most likely at the moment).

I've only seen it when building evcxr, specifically the evcxr_repl binary, but it's the only project I've really been in since I updated my rust toolchain to 1.53.0-nightly (2021-04-23) (the latest one that has the components I use — apologies if this is likely to be fixed in the past 2 weeks) — previously I was over a month older. Also, evcxr_repl is really the main package I build in that project, so... only seeing it in this situation might not mean that much in practice, and could just be coincidental timing.

It doesn't happen always, although it's reasonably frequent. I've seen it with split-debuginfo=packed in addition to the default.

I'm not sure if its relevant, but it's possibly worth noting that evcxr is a project that enables opt-level=2 for debug builds https://github.com/google/evcxr/blob/main/Cargo.toml#L16-L18.


Some versions:

  • macOS: 11.2.1 (20D74) (uh, yeah, I guess I need to update...)
  • Xcode: Version 12.5 (12E262)
$ dsymutil --version
Apple LLVM version 12.0.5 (clang-1205.0.22.9)
  Optimized build.
  Default target: x86_64-apple-darwin20.3.0
  Host CPU: skylake

$ rustc -Vv
rustc 1.53.0-nightly (42816d61e 2021-04-24)
binary: rustc
commit-hash: 42816d61ead7e46d462df997958ccfd514f8c21c
commit-date: 2021-04-24
host: x86_64-apple-darwin
release: 1.53.0-nightly
LLVM version: 12.0.0
@rustbot rustbot added A-codegen Area: Code generation C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants