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

Update references to tsan state #42440

Merged
merged 1 commit into from
Oct 1, 2021
Merged

Update references to tsan state #42440

merged 1 commit into from
Oct 1, 2021

Conversation

Keno
Copy link
Member

@Keno Keno commented Sep 30, 2021

The tsan state got moved into the task struct, but references
to it were not updated. This fixed the build, though the exectuable
itself crashes in LLVM when run. I haven't looked into that yet.

cc @ianatol

The tsan state got moved into the task struct, but references
to it were not updated. This fixed the build, though the exectuable
itself crashes in LLVM when run. I haven't looked into that yet.
@Keno Keno requested a review from vtjnash September 30, 2021 23:47
@tkf
Copy link
Member

tkf commented Oct 1, 2021

FWIW, just as a record, I can get around

    JULIA usr/lib/julia/corecompiler.ji
==================
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=11901)
  Cycle in lock order graph: M2023 (0x7b4400000530) => M3846 (0x7b4400000670) => M2023

  Mutex M3846 acquired here while holding mutex M2023 in main thread:

with

$ grep TSAN_OPTIONS Make.user
export TSAN_OPTIONS=suppressions=$(BUILDROOT)/tsan-suppressions
$ cat tsan-suppressions
deadlock:llvm

but I still get another failure

   JULIA usr/lib/julia/corecompiler.ji
ThreadSanitizer:DEADLYSIGNAL
==31858==ERROR: ThreadSanitizer: SEGV on unknown address 0x00000000014c (pc 0x7f05e1f319bc bp 0x7ffd9b74cd80 sp 0x7ffd9b74cc
b0 T31858)
==31858==The signal is caused by a READ memory access.
==31858==Hint: address points to the zero page.
    #0 llvm::Mangler::getNameWithPrefix(llvm::raw_ostream&, llvm::GlobalValue const*, bool) const ??:? (libLLVM-12jl.so+0xa3
29bc)
    #1 llvm::Mangler::getNameWithPrefix(llvm::SmallVectorImpl<char>&, llvm::GlobalValue const*, bool) const ??:? (libLLVM-12
jl.so+0xa339d8)
    #2 llvm::TargetMachine::getSymbol(llvm::GlobalValue const*) const ??:? (libLLVM-12jl.so+0x25284cc)
    #3 (anonymous namespace)::X86MCInstLower::GetSymbolFromOperand(llvm::MachineOperand const&) const X86MCInstLower.cpp:? (
libLLVM-12jl.so+0x2b57bd4)
    #4 (anonymous namespace)::X86MCInstLower::Lower(llvm::MachineInstr const*, llvm::MCInst&) const [clone .constprop.180] X
86MCInstLower.cpp:? (libLLVM-12jl.so+0x2b5b12a)
    #5 llvm::X86AsmPrinter::emitInstruction(llvm::MachineInstr const*) :? (libLLVM-12jl.so+0x2b5d2c6)
...

@vtjnash
Copy link
Sponsor Member

vtjnash commented Oct 1, 2021

Which lock was that? I maintain a hierarchy document, and I'm only aware of one bad case (modules) that may violate it, but others are hopefully readily fixable.

@tkf
Copy link
Member

tkf commented Oct 1, 2021

Here's the longer output (with the Make.user in #42444)

    LINK /home/arakaki/tmp/test-asan/tsan/usr/lib/libjulia-internal-debug.so.1
    LINK /home/arakaki/tmp/test-asan/tsan/usr/lib/libjulia-internal-debug.so
    JULIA /home/arakaki/tmp/test-asan/tsan/usr/lib/julia/corecompiler.ji
==================
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=101944)
  Cycle in lock order graph: M2023 (0x7b4400000530) => M3846 (0x7b4400000670) => M2023

  Mutex M3846 acquired here while holding mutex M2023 in main thread:
    #0 pthread_mutex_lock /workspace/srcdir/llvm-project/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:4233 (julia-debug+0x467b5b)
    #1 llvm::orc::ExecutionSession::OL_applyQueryPhase1(std::unique_ptr<llvm::orc::InProgressLookupState, std::default_delete<llvm::orc::InProgressLookupState> >, llvm::Error) ??:? (libLLVM-12jl.so+0x245c122)
    #2 JuliaOJIT::findUnmangledSymbol(llvm::StringRef) /home/arakaki/repos/watch/_wt/julia/tsan/src/jitlayers.cpp:808 (libjulia-internal-debug.so.1+0x33dfc4)
    #3 JuliaOJIT::addModule(std::unique_ptr<llvm::Module, std::default_delete<llvm::Module> >) /home/arakaki/repos/watch/_wt/julia/tsan/src/jitlayers.cpp:763 (libjulia-internal-debug.so.1+0x33da55)
    #4 jl_add_to_ee(std::unique_ptr<llvm::Module, std::default_delete<llvm::Module> >) /home/arakaki/repos/watch/_wt/julia/tsan/src/jitlayers.cpp:1065 (libjulia-internal-debug.so.1+0x33897c)
    #5 _jl_compile_codeinst(_jl_code_instance_t*, _jl_code_info_t*, unsigned long) /home/arakaki/repos/watch/_wt/julia/tsan/src/jitlayers.cpp:131 (libjulia-internal-debug.so.1+0x33a055)
    #6 jl_generate_fptr_for_unspecialized /home/arakaki/repos/watch/_wt/julia/tsan/src/jitlayers.cpp:395 (libjulia-internal-debug.so.1+0x33b095)
    #7 jl_compile_method_internal /home/arakaki/repos/watch/_wt/julia/tsan/src/gf.c:1986 (libjulia-internal-debug.so.1+0x1f39de)
    #8 _jl_invoke /home/arakaki/repos/watch/_wt/julia/tsan/src/gf.c:2239 (libjulia-internal-debug.so.1+0x1f7de0)
    #9 ijl_invoke /home/arakaki/repos/watch/_wt/julia/tsan/src/gf.c:2254 (libjulia-internal-debug.so.1+0x1f7baa)
    #10 jl_toplevel_eval_flex /home/arakaki/repos/watch/_wt/julia/tsan/src/toplevel.c:880 (libjulia-internal-debug.so.1+0x282f09)
    #11 jl_parse_eval_all /home/arakaki/repos/watch/_wt/julia/tsan/src/toplevel.c:1023 (libjulia-internal-debug.so.1+0x286ad8)
    #12 ijl_load_ /home/arakaki/repos/watch/_wt/julia/tsan/src/toplevel.c:1070 (libjulia-internal-debug.so.1+0x28626e)
    #13 ijl_load /home/arakaki/repos/watch/_wt/julia/tsan/src/toplevel.c:1083 (libjulia-internal-debug.so.1+0x286e3b)
    #14 _finish_julia_init /home/arakaki/repos/watch/_wt/julia/tsan/src/init.c:766 (libjulia-internal-debug.so.1+0x23e0fb)
    #15 julia_init /home/arakaki/repos/watch/_wt/julia/tsan/src/init.c:733 (libjulia-internal-debug.so.1+0x23dc62)
    #16 jl_repl_entrypoint /home/arakaki/repos/watch/_wt/julia/tsan/src/jlapi.c:684 (libjulia-internal-debug.so.1+0x2e21ed)
    #17 jl_load_repl /home/arakaki/repos/watch/_wt/julia/tsan/cli/loader_lib.c:225 (libjulia-debug.so.1+0xfc8c)
    #18 main /home/arakaki/repos/watch/_wt/julia/tsan/cli/loader_exe.c:59 (julia-debug+0x4d3381)

    Hint: use TSAN_OPTIONS=second_deadlock_stack=1 to get more informative warning message

  Mutex M2023 acquired here while holding mutex M3846 in main thread:
    #0 pthread_mutex_lock /workspace/srcdir/llvm-project/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:4233 (julia-debug+0x467b5b)
    #1 llvm::orc::ExecutionSession::OL_applyQueryPhase1(std::unique_ptr<llvm::orc::InProgressLookupState, std::default_delete<llvm::orc::InProgressLookupState> >, llvm::Error) ??:? (libLLVM-12jl.so+0x245c122)
    #2 jl_add_to_ee(std::unique_ptr<llvm::Module, std::default_delete<llvm::Module> >) /home/arakaki/repos/watch/_wt/julia/tsan/src/jitlayers.cpp:1065 (libjulia-internal-debug.so.1+0x33897c)
    #3 _jl_compile_codeinst(_jl_code_instance_t*, _jl_code_info_t*, unsigned long) /home/arakaki/repos/watch/_wt/julia/tsan/src/jitlayers.cpp:131 (libjulia-internal-debug.so.1+0x33a055)
    #4 jl_generate_fptr_for_unspecialized /home/arakaki/repos/watch/_wt/julia/tsan/src/jitlayers.cpp:395 (libjulia-internal-debug.so.1+0x33b095)
    #5 jl_compile_method_internal /home/arakaki/repos/watch/_wt/julia/tsan/src/gf.c:1986 (libjulia-internal-debug.so.1+0x1f39de)
    #6 _jl_invoke /home/arakaki/repos/watch/_wt/julia/tsan/src/gf.c:2239 (libjulia-internal-debug.so.1+0x1f7de0)
    #7 ijl_invoke /home/arakaki/repos/watch/_wt/julia/tsan/src/gf.c:2254 (libjulia-internal-debug.so.1+0x1f7baa)
    #8 jl_toplevel_eval_flex /home/arakaki/repos/watch/_wt/julia/tsan/src/toplevel.c:880 (libjulia-internal-debug.so.1+0x282f09)
    #9 jl_parse_eval_all /home/arakaki/repos/watch/_wt/julia/tsan/src/toplevel.c:1023 (libjulia-internal-debug.so.1+0x286ad8)
    #10 ijl_load_ /home/arakaki/repos/watch/_wt/julia/tsan/src/toplevel.c:1070 (libjulia-internal-debug.so.1+0x28626e)
    #11 ijl_load /home/arakaki/repos/watch/_wt/julia/tsan/src/toplevel.c:1083 (libjulia-internal-debug.so.1+0x286e3b)
    #12 _finish_julia_init /home/arakaki/repos/watch/_wt/julia/tsan/src/init.c:766 (libjulia-internal-debug.so.1+0x23e0fb)
    #13 julia_init /home/arakaki/repos/watch/_wt/julia/tsan/src/init.c:733 (libjulia-internal-debug.so.1+0x23dc62)
    #14 jl_repl_entrypoint /home/arakaki/repos/watch/_wt/julia/tsan/src/jlapi.c:684 (libjulia-internal-debug.so.1+0x2e21ed)
    #15 jl_load_repl /home/arakaki/repos/watch/_wt/julia/tsan/cli/loader_lib.c:225 (libjulia-debug.so.1+0xfc8c)
    #16 main /home/arakaki/repos/watch/_wt/julia/tsan/cli/loader_exe.c:59 (julia-debug+0x4d3381)

SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) ??:? in llvm::orc::ExecutionSession::OL_applyQueryPhase1(std::unique_ptr<llvm::orc::InProgressLookupState, std::default_delete<llvm::orc::InProgressLookupState> >, llvm::Error)
==================
ThreadSanitizer:DEADLYSIGNAL
==101944==ERROR: ThreadSanitizer: SEGV on unknown address 0x00000000014c (pc 0x7fdd642319bc bp 0x7ffc16b7b090 sp 0x7ffc16b7afc0 T101944)
==101944==The signal is caused by a READ memory access.
==101944==Hint: address points to the zero page.
    #0 llvm::Mangler::getNameWithPrefix(llvm::raw_ostream&, llvm::GlobalValue const*, bool) const ??:? (libLLVM-12jl.so+0xa329bc)
    #1 llvm::Mangler::getNameWithPrefix(llvm::SmallVectorImpl<char>&, llvm::GlobalValue const*, bool) const ??:? (libLLVM-12jl.so+0xa339d8)
    #2 llvm::TargetMachine::getSymbol(llvm::GlobalValue const*) const ??:? (libLLVM-12jl.so+0x25284cc)
    #3 (anonymous namespace)::X86MCInstLower::GetSymbolFromOperand(llvm::MachineOperand const&) const X86MCInstLower.cpp:? (libLLVM-12jl.so+0x2b57bd4)
    #4 (anonymous namespace)::X86MCInstLower::Lower(llvm::MachineInstr const*, llvm::MCInst&) const [clone .constprop.180] X86MCInstLower.cpp:? (libLLVM-12jl.so+0x2b5b12a)
    #5 llvm::X86AsmPrinter::emitInstruction(llvm::MachineInstr const*) :? (libLLVM-12jl.so+0x2b5d2c6)
    #6 llvm::AsmPrinter::emitFunctionBody() ??:? (libLLVM-12jl.so+0x11c1eee)
    #7 llvm::X86AsmPrinter::runOnMachineFunction(llvm::MachineFunction&) :? (libLLVM-12jl.so+0x2958a9e)
    #8 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) ??:? (libLLVM-12jl.so+0xcb3aa7)
    #9 llvm::FPPassManager::runOnFunction(llvm::Function&) ??:? (libLLVM-12jl.so+0xa2eece)
    #10 llvm::FPPassManager::runOnModule(llvm::Module&) ??:? (libLLVM-12jl.so+0xa2f5b0)
    #11 llvm::legacy::PassManagerImpl::run(llvm::Module&) ??:? (libLLVM-12jl.so+0xa2e296)
    #12 JuliaOJIT::CompilerT::operator()(llvm::Module&) /home/arakaki/repos/watch/_wt/julia/tsan/src/jitlayers.cpp:610 (libjulia-internal-debug.so.1+0x33be8a)
    #13 llvm::orc::IRCompileLayer::emit(std::unique_ptr<llvm::orc::MaterializationResponsibility, std::default_delete<llvm::orc::MaterializationResponsibility> >, llvm::orc::ThreadSafeModule) ??:? (libLLVM-12jl.so+0x2485434)
    #14 llvm::orc::BasicIRLayerMaterializationUnit::materialize(std::unique_ptr<llvm::orc::MaterializationResponsibility, std::default_delete<llvm::orc::MaterializationResponsibility> >) ??:? (libLLVM-12jl.so+0x2490560)
    #15 llvm::orc::ExecutionSession::materializeOnCurrentThread(std::unique_ptr<llvm::orc::MaterializationUnit, std::default_delete<llvm::orc::MaterializationUnit> >, std::unique_ptr<llvm::orc::MaterializationResponsibility, std::default_delete<llvm::orc::MaterializationResponsibility> >) :? (libLLVM-12jl.so+0x2465664)
    #16 std::_Function_handler<void (std::unique_ptr<llvm::orc::MaterializationUnit, std::default_delete<llvm::orc::MaterializationUnit> >, std::unique_ptr<llvm::orc::MaterializationResponsibility, std::default_delete<llvm::orc::MaterializationResponsibility> >), void (*)(std::unique_ptr<llvm::orc::MaterializationUnit, std::default_delete<llvm::orc::MaterializationUnit> >, std::unique_ptr<llvm::orc::MaterializationResponsibility, std::default_delete<llvm::orc::MaterializationResponsibility> >)>::_M_invoke(std::_Any_data const&, std::unique_ptr<llvm::orc::MaterializationUnit, std::default_delete<llvm::orc::MaterializationUnit> >&&, std::unique_ptr<llvm::orc::MaterializationResponsibility, std::default_delete<llvm::orc::MaterializationResponsibility> >&&) ??:? (libLLVM-12jl.so+0x246364d)
    #17 llvm::orc::ExecutionSession::dispatchOutstandingMUs() ??:? (libLLVM-12jl.so+0x2463e18)
    #18 llvm::orc::ExecutionSession::OL_completeLookup(std::unique_ptr<llvm::orc::InProgressLookupState, std::default_delete<llvm::orc::InProgressLookupState> >, std::shared_ptr<llvm::orc::AsynchronousSymbolQuery>, std::function<void (llvm::DenseMap<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr> >, llvm::DenseMapInfo<llvm::orc::JITDylib*>, llvm::detail::DenseMapPair<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr> > > > const&)>) ??:? (libLLVM-12jl.so+0x246c339)
    #19 llvm::orc::InProgressFullLookupState::complete(std::unique_ptr<llvm::orc::InProgressLookupState, std::default_delete<llvm::orc::InProgressLookupState> >) :? (libLLVM-12jl.so+0x246d1cc)
    #20 llvm::orc::ExecutionSession::OL_applyQueryPhase1(std::unique_ptr<llvm::orc::InProgressLookupState, std::default_delete<llvm::orc::InProgressLookupState> >, llvm::Error) ??:? (libLLVM-12jl.so+0x245c5ed)
    #21 llvm::orc::ExecutionSession::lookup(llvm::orc::LookupKind, std::vector<std::pair<llvm::orc::JITDylib*, llvm::orc::JITDylibLookupFlags>, std::allocator<std::pair<llvm::orc::JITDylib*, llvm::orc::JITDylibLookupFlags> > > const&, llvm::orc::SymbolLookupSet, llvm::orc::SymbolState, llvm::unique_function<void (llvm::Expected<llvm::DenseMap<llvm::orc::SymbolStringPtr, llvm::JITEvaluatedSymbol, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr>, llvm::detail::DenseMapPair<llvm::orc::SymbolStringPtr, llvm::JITEvaluatedSymbol> > >)>, std::function<void (llvm::DenseMap<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr> >, llvm::DenseMapInfo<llvm::orc::JITDylib*>, llvm::detail::DenseMapPair<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr> > > > const&)>) ??:? (libLLVM-12jl.so+0x246424e)
    #22 llvm::orc::ExecutionSession::lookup(std::vector<std::pair<llvm::orc::JITDylib*, llvm::orc::JITDylibLookupFlags>, std::allocator<std::pair<llvm::orc::JITDylib*, llvm::orc::JITDylibLookupFlags> > > const&, llvm::orc::SymbolLookupSet const&, llvm::orc::LookupKind, llvm::orc::SymbolState, std::function<void (llvm::DenseMap<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr> >, llvm::DenseMapInfo<llvm::orc::JITDylib*>, llvm::detail::DenseMapPair<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr> > > > const&)>) ??:? (libLLVM-12jl.so+0x2464a93)
    #23 llvm::orc::ExecutionSession::lookup(std::vector<std::pair<llvm::orc::JITDylib*, llvm::orc::JITDylibLookupFlags>, std::allocator<std::pair<llvm::orc::JITDylib*, llvm::orc::JITDylibLookupFlags> > > const&, llvm::orc::SymbolStringPtr, llvm::orc::SymbolState) ??:? (libLLVM-12jl.so+0x2464e75)
    #24 llvm::orc::ExecutionSession::lookup(llvm::ArrayRef<llvm::orc::JITDylib*>, llvm::orc::SymbolStringPtr, llvm::orc::SymbolState) ??:? (libLLVM-12jl.so+0x246526f)
    #25 llvm::orc::ExecutionSession::lookup(llvm::ArrayRef<llvm::orc::JITDylib*>, llvm::StringRef, llvm::orc::SymbolState) ??:? (libLLVM-12jl.so+0x2465493)
    #26 JuliaOJIT::addModule(std::unique_ptr<llvm::Module, std::default_delete<llvm::Module> >) /home/arakaki/repos/watch/_wt/julia/tsan/src/jitlayers.cpp:785 (libjulia-internal-debug.so.1+0x33dde5)
    #27 jl_add_to_ee(std::unique_ptr<llvm::Module, std::default_delete<llvm::Module> >) /home/arakaki/repos/watch/_wt/julia/tsan/src/jitlayers.cpp:1065 (libjulia-internal-debug.so.1+0x33897c)
    #28 jl_add_to_ee(std::unique_ptr<llvm::Module, std::default_delete<llvm::Module> >&, llvm::StringMap<std::unique_ptr<llvm::Module, std::default_delete<llvm::Module> >*, llvm::MallocAllocator>&, llvm::DenseMap<llvm::Module*, int, llvm::DenseMapInfo<llvm::Module*>, llvm::detail::DenseMapPair<llvm::Module*, int> >&, std::vector<std::vector<std::unique_ptr<llvm::Module, std::default_delete<llvm::Module> >*, std::allocator<std::unique_ptr<llvm::Module, std::default_delete<llvm::Module> >*> >, std::allocator<std::vector<std::unique_ptr<llvm::Module, std::default_delete<llvm::Module> >*, std::allocator<std::unique_ptr<llvm::Module, std::default_delete<llvm::Module> >*> > > >&, int) /home/arakaki/repos/watch/_wt/julia/tsan/src/jitlayers.cpp:1109 (libjulia-internal-debug.so.1+0x33fe48)
    #29 jl_add_to_ee(std::unique_ptr<llvm::Module, std::default_delete<llvm::Module> >&, llvm::StringMap<std::unique_ptr<llvm::Module, std::default_delete<llvm::Module> >*, llvm::MallocAllocator>&) /home/arakaki/repos/watch/_wt/julia/tsan/src/jitlayers.cpp:1131 (libjulia-internal-debug.so.1+0x33f777)
    #30 _jl_compile_codeinst(_jl_code_instance_t*, _jl_code_info_t*, unsigned long) /home/arakaki/repos/watch/_wt/julia/tsan/src/jitlayers.cpp:155 (libjulia-internal-debug.so.1+0x33a52f)
    #31 jl_generate_fptr_for_unspecialized /home/arakaki/repos/watch/_wt/julia/tsan/src/jitlayers.cpp:395 (libjulia-internal-debug.so.1+0x33b095)
    #32 jl_compile_method_internal /home/arakaki/repos/watch/_wt/julia/tsan/src/gf.c:1986 (libjulia-internal-debug.so.1+0x1f39de)
    #33 _jl_invoke /home/arakaki/repos/watch/_wt/julia/tsan/src/gf.c:2239 (libjulia-internal-debug.so.1+0x1f7de0)
    #34 ijl_apply_generic /home/arakaki/repos/watch/_wt/julia/tsan/src/gf.c:2429 (libjulia-internal-debug.so.1+0x1f7f69)
    #35 jl_apply /home/arakaki/repos/watch/_wt/julia/tsan/src/julia.h:1778 (libjulia-internal-debug.so.1+0x23891c)
    #36 do_call /home/arakaki/repos/watch/_wt/julia/tsan/src/interpreter.c:126 (libjulia-internal-debug.so.1+0x238349)
    #37 eval_value /home/arakaki/repos/watch/_wt/julia/tsan/src/interpreter.c:215 (libjulia-internal-debug.so.1+0x2352df)
    #38 eval_stmt_value /home/arakaki/repos/watch/_wt/julia/tsan/src/interpreter.c:166 (libjulia-internal-debug.so.1+0x237825)
    #39 eval_body /home/arakaki/repos/watch/_wt/julia/tsan/src/interpreter.c:583 (libjulia-internal-debug.so.1+0x2333d4)
    #40 jl_interpret_toplevel_thunk /home/arakaki/repos/watch/_wt/julia/tsan/src/interpreter.c:731 (libjulia-internal-debug.so.1+0x2342aa)
    #41 jl_toplevel_eval_flex /home/arakaki/repos/watch/_wt/julia/tsan/src/toplevel.c:889 (libjulia-internal-debug.so.1+0x283010)
    #42 jl_parse_eval_all /home/arakaki/repos/watch/_wt/julia/tsan/src/toplevel.c:1023 (libjulia-internal-debug.so.1+0x286ad8)
    #43 ijl_load_ /home/arakaki/repos/watch/_wt/julia/tsan/src/toplevel.c:1070 (libjulia-internal-debug.so.1+0x28626e)
    #44 ijl_load /home/arakaki/repos/watch/_wt/julia/tsan/src/toplevel.c:1083 (libjulia-internal-debug.so.1+0x286e3b)
    #45 _finish_julia_init /home/arakaki/repos/watch/_wt/julia/tsan/src/init.c:766 (libjulia-internal-debug.so.1+0x23e0fb)
    #46 julia_init /home/arakaki/repos/watch/_wt/julia/tsan/src/init.c:733 (libjulia-internal-debug.so.1+0x23dc62)
    #47 jl_repl_entrypoint /home/arakaki/repos/watch/_wt/julia/tsan/src/jlapi.c:684 (libjulia-internal-debug.so.1+0x2e21ed)
    #48 jl_load_repl /home/arakaki/repos/watch/_wt/julia/tsan/cli/loader_lib.c:225 (libjulia-debug.so.1+0xfc8c)
    #49 main /home/arakaki/repos/watch/_wt/julia/tsan/cli/loader_exe.c:59 (julia-debug+0x4d3381)
    #50 __libc_start_main /build/glibc-S7xCS9/glibc-2.27/csu/../csu/libc-start.c:310 (libc.so.6+0x21bf6)
    #51 _start ??:? (julia-debug+0x41e879)

ThreadSanitizer can not provide additional info.
SUMMARY: ThreadSanitizer: SEGV ??:? in llvm::Mangler::getNameWithPrefix(llvm::raw_ostream&, llvm::GlobalValue const*, bool) const
==101944==ABORTING
/home/arakaki/repos/watch/_wt/julia/tsan/sysimage.mk:61: recipe for target '/home/arakaki/tmp/test-asan/tsan/usr/lib/julia/corecompiler.ji' failed
make[1]: *** [/home/arakaki/tmp/test-asan/tsan/usr/lib/julia/corecompiler.ji] Error 66
/home/arakaki/repos/watch/_wt/julia/tsan/Makefile:82: recipe for target 'julia-sysimg-ji' failed
make: *** [julia-sysimg-ji] Error 2

@Keno
Copy link
Member Author

Keno commented Oct 1, 2021

but I still get another failure

Yes, this is the failure I'm looking into. Looks like a reference to jl_gc_alloc is being kept past the destruction of the corresponding module. Not sure why yet. Perhaps the TSAN instrumentation pass is capturing it.

@Keno
Copy link
Member Author

Keno commented Oct 1, 2021

I'm gonna go ahead and merge this, so @tkf can play with the CI setup, since at least it builds with this. It might still be wrong, since it didn't get far enough in the run to actually exercise the task system, but I can fix that as a follow up if so.

@Keno Keno merged commit 15772ba into master Oct 1, 2021
@Keno Keno deleted the kf/tsanstate branch October 1, 2021 04:44
@Keno
Copy link
Member Author

Keno commented Oct 1, 2021

tsan_cleanup:                                     ; preds = %top, %thread_ptr.noexc, %L4
  %cleanup.lpad = landingpad { i8*, i32 }
          cleanup
  call void @__tsan_func_exit()
  %exn.obj = extractvalue { i8*, i32 } %cleanup.lpad, 0
  call void <badref>(i8* %exn.obj) #7
  unreachable

is what it's trying to compile - not sure what it's trying to do there.

@Keno
Copy link
Member Author

Keno commented Oct 1, 2021

@tkf I found the LLVM issue. Somebody dropped llvm/llvm-project@66b0cebf7f736 during an overeager refactoring. Would you be willing to submit a patch upstream to re-enable it and add a test (use the -run-twice command line option to llc/opt to test this)?

@Keno
Copy link
Member Author

Keno commented Oct 1, 2021

WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=11901)

@tkf, I can't reproduce this. Given your backtrace and #42444, I would make sure you're building LLVM with tsan instrumentation enabled.

@tkf
Copy link
Member

tkf commented Oct 1, 2021

Ah, thanks! Yes, indeed, I was just using LLVM from BB. I'll try it with the custom build.

Would you be willing to submit a patch upstream to re-enable it and add a test (use the -run-twice command line option to llc/opt to test this)?

I'm afraid I'm not familiar at all with that part of LLVM (not that there are parts of the mainline LLVM that I know reasonably well, though).

@Keno
Copy link
Member Author

Keno commented Oct 1, 2021

I'm afraid I'm not familiar at all with that part of LLVM (not that there are parts of the mainline LLVM that I know reasonably well, though).

That's why I proposed this one, it should be very easy. You literally just need to re-apply that patch to fix it :). For the test, I think just adding -run-twice to this line will do it: https://github.com/llvm/llvm-project/blob/d480f968ad8b56d3ee4a6b6df5532d485b0ad01e/llvm/test/CodeGen/X86/dwarf-eh-prepare.ll#L1

Keno added a commit that referenced this pull request Oct 1, 2021
@tkf
Copy link
Member

tkf commented Oct 1, 2021

Right, I had to apply the patch to DwarfEHPrepareLegacyPass instead of DwarfEHPrepare but yeah, it was straightforward other than that

llvm/llvm-project@main...tkf:fix-dwarf-eh

@Keno
Copy link
Member Author

Keno commented Oct 1, 2021

Great, I'd

  1. Make sure the test actually fails with an un-patched LLVM and
  2. Submit it at https://reviews.llvm.org/

@tkf
Copy link
Member

tkf commented Oct 1, 2021

Yeah, llvm-lit was the first thing I tried. I posted it to https://reviews.llvm.org/D110979. Let me know if there are more details to fill. (I guess I now need to find reviewers...)

vtjnash pushed a commit that referenced this pull request Oct 3, 2021
vtjnash pushed a commit that referenced this pull request Oct 7, 2021
This reverts commit 15772ba
"Update references to tsan state (#42440)", and fixes integration.

Looks like #36929 got reverted
when trying to simplify the code, but it now isn't legal. Since these
must be inlined in the right point in the runtime call/return context,
use a macro to ensure that.
vtjnash pushed a commit that referenced this pull request Oct 8, 2021
This reverts commit 15772ba
"Update references to tsan state (#42440)", and fixes integration.

Looks like #36929 got reverted
when trying to simplify the code, but it now isn't legal. Since these
must be inlined in the right point in the runtime call/return context,
use a macro to ensure that.
vtjnash pushed a commit that referenced this pull request Oct 14, 2021
This reverts commit 15772ba
"Update references to tsan state (#42440)", and fixes integration.

Looks like #36929 got reverted
when trying to simplify the code, but it now isn't legal. Since these
must be inlined in the right point in the runtime call/return context,
use a macro to ensure that.
vtjnash pushed a commit that referenced this pull request Oct 14, 2021
This reverts commit 15772ba
"Update references to tsan state (#42440)", and fixes integration.

Looks like #36929 got reverted
when trying to simplify the code, but it now isn't legal. Since these
must be inlined in the right point in the runtime call/return context,
use a macro to ensure that.
LilithHafner pushed a commit to LilithHafner/julia that referenced this pull request Feb 22, 2022
The tsan state got moved into the task struct, but references
to it were not updated. This fixed the build, though the exectuable
itself crashes in LLVM when run. I haven't looked into that yet.
LilithHafner pushed a commit to LilithHafner/julia that referenced this pull request Feb 22, 2022
This reverts commit 15772ba
"Update references to tsan state (JuliaLang#42440)", and fixes integration.

Looks like JuliaLang#36929 got reverted
when trying to simplify the code, but it now isn't legal. Since these
must be inlined in the right point in the runtime call/return context,
use a macro to ensure that.
LilithHafner pushed a commit to LilithHafner/julia that referenced this pull request Mar 8, 2022
The tsan state got moved into the task struct, but references
to it were not updated. This fixed the build, though the exectuable
itself crashes in LLVM when run. I haven't looked into that yet.
LilithHafner pushed a commit to LilithHafner/julia that referenced this pull request Mar 8, 2022
This reverts commit 15772ba
"Update references to tsan state (JuliaLang#42440)", and fixes integration.

Looks like JuliaLang#36929 got reverted
when trying to simplify the code, but it now isn't legal. Since these
must be inlined in the right point in the runtime call/return context,
use a macro to ensure that.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants