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

Assertion failing in constructAbstractSubprogramScopeDIE if compiled with -g #14930

Closed
farcaller opened this issue Jun 16, 2014 · 15 comments
Closed
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.)

Comments

@farcaller
Copy link
Contributor

Assertion failed: (ScopeDIE), function constructAbstractSubprogramScopeDIE
file /Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 534.

What interesting is that it fails with rust nightly but works ok with my local rust configuration:

% /Users/farcaller/Downloads/rust-nightly-x86_64-apple-darwin/bin/rustc --version
rustc 0.11.0-pre-nightly (6d8342f 2014-06-14 17:51:49 +0000)
host: x86_64-apple-darwin
% ~/.local/bin/rustc --version
rustc 0.11.0-pre (6d8342f 2014-06-14 17:51:49 +0000)
host: x86_64-apple-darwin

Update: those timestamps look to same, that's probably not a coincidence :-) anyways, my local rustc is surely built from 6d8342f.

My rust was configured as

./configure --prefix=/Users/farcaller/.local --enable-clang --disable-docs --disable-optimize --disable-optimize-cxx --disable-optimize-llvm --disable-verify-install
@farcaller
Copy link
Contributor Author

Stack trace:

* thread #2: tid = 0x48de0a, 0x00007fff83546866 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
  * frame #0: 0x00007fff83546866 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff865e135c libsystem_pthread.dylib`pthread_kill + 92
    frame #2: 0x00000001016b3b16 librustc-d252d482-0.11.0-pre.dylib`abort + 22
    frame #3: 0x00000001016b3af1 librustc-d252d482-0.11.0-pre.dylib`__assert_rtn + 81
    frame #4: 0x000000010103c2fd librustc-d252d482-0.11.0-pre.dylib`llvm::DwarfDebug::constructAbstractSubprogramScopeDIE(llvm::DwarfCompileUnit&, llvm::LexicalScope*) + 349
    frame #5: 0x0000000101042ab9 librustc-d252d482-0.11.0-pre.dylib`llvm::DwarfDebug::endFunction(llvm::MachineFunction const*) + 1449
    frame #6: 0x00000001010234ad librustc-d252d482-0.11.0-pre.dylib`llvm::AsmPrinter::EmitFunctionBody() + 4637
    frame #7: 0x0000000100c3270a librustc-d252d482-0.11.0-pre.dylib`llvm::ARMAsmPrinter::runOnMachineFunction(llvm::MachineFunction&) + 362
    frame #8: 0x000000010112c41d librustc-d252d482-0.11.0-pre.dylib`llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 125
    frame #9: 0x0000000101649bab librustc-d252d482-0.11.0-pre.dylib`llvm::FPPassManager::runOnFunction(llvm::Function&) + 347
    frame #10: 0x0000000101649e4b librustc-d252d482-0.11.0-pre.dylib`llvm::FPPassManager::runOnModule(llvm::Module&) + 59
    frame #11: 0x000000010164a429 librustc-d252d482-0.11.0-pre.dylib`llvm::legacy::PassManagerImpl::run(llvm::Module&) + 1081
    frame #12: 0x000000010164a83d librustc-d252d482-0.11.0-pre.dylib`llvm::legacy::PassManager::run(llvm::Module&) + 13
    frame #13: 0x0000000100a71e23 librustc-d252d482-0.11.0-pre.dylib`LLVMRustWriteOutputFile + 307
    frame #14: 0x00000001008d71dd librustc-d252d482-0.11.0-pre.dylib`back::link::write_output_file::he9e93a5b7a268ff2wKf::v0.11.0.pre + 141
    frame #15: 0x00000001008dea30 librustc-d252d482-0.11.0-pre.dylib`back::link::write::run_passes::closure.91419 + 240
    frame #16: 0x00000001008d976c librustc-d252d482-0.11.0-pre.dylib`back::link::write::run_passes::hbb695e52f514c879MMf::v0.11.0.pre + 9356
    frame #17: 0x0000000100a20e01 librustc-d252d482-0.11.0-pre.dylib`driver::driver::phase_5_run_llvm_passes::closure.97852 + 97
    frame #18: 0x0000000100989c7a librustc-d252d482-0.11.0-pre.dylib`driver::driver::phase_5_run_llvm_passes::h7e7bf09cf59529cafxv::v0.11.0.pre + 490
    frame #19: 0x000000010097f380 librustc-d252d482-0.11.0-pre.dylib`driver::driver::compile_input::hf1998b432ab27ab2gbv::v0.11.0.pre + 7456
    frame #20: 0x0000000100a406ee librustc-d252d482-0.11.0-pre.dylib`driver::run_compiler::hb2048e6d930cfe5fOSx::v0.11.0.pre + 9662
    frame #21: 0x0000000100a3e076 librustc-d252d482-0.11.0-pre.dylib`driver::main_args::closure.98543 + 70
    frame #22: 0x0000000100a58397 librustc-d252d482-0.11.0-pre.dylib`driver::monitor::closure.99633 + 199
    frame #23: 0x0000000100a535bb librustc-d252d482-0.11.0-pre.dylib`task::TaskBuilder::try::closure.99396 + 75
    frame #24: 0x00000001000459ac libnative-1fb5e2c0-0.11.0-pre.dylib`task::spawn_opts::closure.7247 + 76
    frame #25: 0x000000010327b928 librustrt-d8560cb2-0.11.0-pre.dylib`task::Task::run::closure.5244 + 56
    frame #26: 0x00000001032f1c2c librustrt-d8560cb2-0.11.0-pre.dylib`rust_try + 12
    frame #27: 0x000000010327e23a librustrt-d8560cb2-0.11.0-pre.dylib`unwind::try::habea3eb6fbe31bfdLCd::v0.11.0.pre + 74
    frame #28: 0x000000010327b7f5 librustrt-d8560cb2-0.11.0-pre.dylib`task::Task::run::h31070b5f512029c7XSc::v0.11.0.pre + 101
    frame #29: 0x000000010004581b libnative-1fb5e2c0-0.11.0-pre.dylib`task::spawn_opts::closure.7219 + 267
    frame #30: 0x000000010327d879 librustrt-d8560cb2-0.11.0-pre.dylib`thread::thread_start::hfa0dfbb777e33e5dmad::v0.11.0.pre + 41
    frame #31: 0x00007fff865e0899 libsystem_pthread.dylib`_pthread_body + 138
    frame #32: 0x00007fff865e072a libsystem_pthread.dylib`_pthread_start + 137

@michaelwoerister
Copy link
Member

Thanks for the report! I'll see if I can reproduce it.

@farcaller
Copy link
Contributor Author

I've rebuilt my local rustc with following:

./configure --prefix=/Users/farcaller/.local --enable-clang --disable-docs --disable-verify-install

and strangely enough the problem seems to be fixed for both local & nightly installs (well, I suppose nightly actually uses libs from local 😄 )

@michaelwoerister
Copy link
Member

That's possible, I don't know the intricacies of the build system too well :) I'll close the issue. If you come across the assertion again, we can always reopen.

@farcaller
Copy link
Contributor Author

For now it's known broken on a clean host install of rust-nightly. Can you please reopen? I'll confirm if that will happen with next nightly build.

@huonw huonw reopened this Jun 16, 2014
@michaelwoerister
Copy link
Member

Woops, thanks @huonw.

@farcaller
Copy link
Contributor Author

All tests are done on a clean linux/x86_64 images:

  • nightly package 0.11.0-pre-nightly (6d8342f 2014-06-14 17:51:49 +0000)fails
  • compiled from 6d8342f with ./configure --disable-docs --disable-verify-installfails
  • compiled from 5abf794 (latest HEAD) – fails

@farcaller
Copy link
Contributor Author

A bit more details, now that I have rustc failing in debug configuration.

In constructAbstractSubprogramScopeDIE call, Scope dumps as:

(gdb) call Scope->dump(0)
DFSIn: 0 DFSOut: 0
!{i32 786478, metadata <badref>, metadata <badref>, metadata !"get_task_stack_pointer", metadata !"get_task_stack_pointer", metadata !"_ZN4zinc3hal9cortex_m35sched22get_task_stack_pointerE", i32 43, metadata <badref>, i1 false, i1 true, i32 0, i32 0, null, i32 256, i1 true, null, metadata <badref>, null, metadata <badref>, i32 43} ; [ DW_TAG_subprogram ] [line 43] [def] [get_task_stack_pointer]

Abstract Scope
  Children ...
  DFSIn: 0 DFSOut: 0
  !{i32 786443, metadata <badref>, metadata <badref>, i32 43, i32 39, i32 0, i32 473} ; [ DW_TAG_lexical_block ] [/tmp/zinc/src/hal/cortex_m3/sched.rs]

  Abstract Scope
    Children ...
    DFSIn: 0 DFSOut: 0
    !{i32 786443, metadata <badref>, metadata <badref>, i32 45, i32 2, i32 0, i32 474} ; [ DW_TAG_lexical_block ] [/tmp/zinc/src/hal/cortex_m3/sched.rs]

    Abstract Scope

FWIW, this is the definition of get_task_stack_pointer:

/// Returns task stack pointer (PSP).
#[cfg(not(test))]
#[inline(always)]
pub fn get_task_stack_pointer() -> u32 {
  let mut val: u32;
  unsafe { asm!("mrs $0, psp" : "=r"(val)) };
  val
}

@farcaller
Copy link
Contributor Author

This might also be of interest (it points to here).

(gdb) call Sub.dump()
[ DW_TAG_subprogram ] [line 43] [def] [get_task_stack_pointer]

@michaelwoerister
Copy link
Member

@farcaller Thanks a lot for the detailed information.

@farcaller
Copy link
Contributor Author

Just a quick followup: I tried to reproduce this in a single file, so far with no success. If you wonder, the code is being compiled with the following flags:

rustc \
  --opt-level 2 \
  -Z no-landing-pads \
  -g \
  --cfg cfg_mcu_has_spi --cfg cfg_tft_lcd --cfg cfg_multitasking --cfg mcu_lpc17xx --cfg arch_cortex_m3 \
  --target thumbv7m-linux-eabi \
  -Ctarget-cpu=cortex-m3 \
  -Crelocation_model=static

@steveklabnik
Copy link
Member

@farcaller it's been a while, is this still failing for you?

@farcaller
Copy link
Contributor Author

Haven't seen it in a while.

@steveklabnik
Copy link
Member

Okay, then I'm going to give it a close. If we see it pop up again, let me know!

@ticki
Copy link
Contributor

ticki commented Jan 5, 2016

It's broken again.

lambda-fairy added a commit to lambda-fairy/gensokyo that referenced this issue Jun 2, 2016
* Without LTO, the executable will crash under VirtualBox. I'm not sure
  why but I'm not going to bother figuring that out.

* LTO and debugging symbols don't mix, so disable the latter for now.
  See <rust-lang/rust#14930>.
RalfJung pushed a commit to RalfJung/rust that referenced this issue Aug 1, 2024
… r=Veykril

fix: let glob imports override other globs' visibility

Follow up to rust-lang#14930

Fixes rust-lang#11858
Fixes rust-lang#14902
Fixes rust-lang#17704

I haven't reworked the code here at all - I don't feel confident in the codebase to do so - just rebased it onto the current main branch and fixed conflicts.

I'm not _entirely_ sure I understand the structure of the `check` function in `crates/hir-def/src/nameres` tests. I think the change to the test expectation from rust-lang#14930 is correct, marking the `crate::reexport::inner` imports with `i`, and I understand it to mean there's a specific token in the import that we can match it to (in this case, `Trait`, `function` and `makro` of `pub use crate::defs::{Trait, function, makro};` respectively), but I had some trouble understanding the meaning of the different parts of `PerNs` to be sure.
Does this make sense?

I tested building and using RA locally with `cargo xtask install` and after this change the documentation for `arrow_array::ArrowPrimitiveType` seems to be picked up correctly!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.)
Projects
None yet
Development

No branches or pull requests

5 participants