Bug 216117 - clang 4.0.0 crashes trying to build lld on i386
Summary: clang 4.0.0 crashes trying to build lld on i386
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-toolchain mailing list
URL:
Keywords:
Depends on:
Blocks: 216008
  Show dependency treegraph
 
Reported: 2017-01-15 16:40 UTC by Jan Beich
Modified: 2017-01-16 19:54 UTC (History)
2 users (show)

See Also:


Attachments
OutputSections-8d5025.cpp (compressed) (525.52 KB, application/x-xz)
2017-01-15 16:44 UTC, Jan Beich
no flags Details
OutputSections-8d5025.sh (4.55 KB, text/plain)
2017-01-15 16:45 UTC, Jan Beich
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer 2017-01-15 16:40:42 UTC
The following error happens only with 32bit /usr/bin/clang but not via -m32. I'm using a custom kernel which is (re)based on drm-next but it doesn't exhibit issues on 10.3 i386 or 11.0 i386.

FAILED: tools/lld/ELF/CMakeFiles/lldELF.dir/OutputSections.cpp.o 
/usr/bin/c++   -DGTEST_HAS_RTTI=0 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/lld/ELF -I/wrkdirs/usr/ports/devel/llvm39/work/llvm-3.9.1.src/tools/lld/ELF -I/wrkdirs/usr/ports/devel/llvm39/work/llvm-3.9.1.src/tools/lld/include -Itools/lld/include -Iinclude -I/wrkdirs/usr/ports/devel/llvm39/work/llvm-3.9.1.src/include -I/usr/local/include -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing  -isystem /usr/local/include -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Werror=date-time -std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing  -isystem /usr/local/include    -fno-exceptions -fno-rtti -MD -MT tools/lld/ELF/CMakeFiles/lldELF.dir/OutputSections.cpp.o -MF tools/lld/ELF/CMakeFiles/lldELF.dir/OutputSections.cpp.o.d -o tools/lld/ELF/CMakeFiles/lldELF.dir/OutputSections.cpp.o -c /wrkdirs/usr/ports/devel/llvm39/work/llvm-3.9.1.src/tools/lld/ELF/OutputSections.cpp
c++: error: unable to execute command: Segmentation fault
c++: error: clang frontend command failed due to signal (use -v to see invocation)
FreeBSD clang version 4.0.0 (branches/release_40 292009) (based on LLVM 4.0.0)
Target: i386-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
c++: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
c++: note: diagnostic msg: /tmp/OutputSections-f012c9.cpp
c++: note: diagnostic msg: /tmp/OutputSections-f012c9.sh
c++: note: diagnostic msg:
Comment 1 Jan Beich freebsd_committer 2017-01-15 16:42:56 UTC
Oops, this is for /projects/clang400-import@312229.
Comment 2 Jan Beich freebsd_committer 2017-01-15 16:44:29 UTC
Created attachment 178923 [details]
OutputSections-8d5025.cpp (compressed)
Comment 3 Jan Beich freebsd_committer 2017-01-15 16:45:06 UTC
Created attachment 178924 [details]
OutputSections-8d5025.sh
Comment 4 Dimitry Andric freebsd_committer 2017-01-15 18:34:16 UTC
Hm, yes, I'm seeing this too, while building llvm38 even.  Something is rotten, but it's hard to figure out what.  For some reason, a cleanly built release_40 r292009 on universe12a.f.o works fine, but on my local system, it doesn't.

I'm trying valgrind to figure out what is going wrong, and it gives me:

==1793== Invalid read of size 8
==1793==    at 0x227C9BE: llvm::ValueHandleBase::AddToUseList() (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x29A3F2D: llvm::AssumptionCache::AffectedValueCallbackVH::allUsesReplacedWith(llvm::Value*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x227A884: llvm::ValueHandleBase::ValueIsRAUWd(llvm::Value*, llvm::Value*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x227A504: llvm::Value::doRAUW(llvm::Value*, bool) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x1C9791E: llvm::sroa::AllocaSliceRewriter::visitLoadInst(llvm::LoadInst&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x1C880FD: llvm::sroa::AllocaSliceRewriter::visit((anonymous namespace)::Slice const*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x1C86C9A: llvm::SROA::rewritePartition(llvm::AllocaInst&, llvm::sroa::AllocaSlices&, llvm::sroa::Partition&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x1C88584: llvm::SROA::splitAlloca(llvm::AllocaInst&, llvm::sroa::AllocaSlices&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x1C89A1D: llvm::SROA::runOnAlloca(llvm::AllocaInst&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x1C8B309: llvm::SROA::runImpl(llvm::Function&, llvm::DominatorTree&, llvm::AssumptionCache&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x1C9C239: llvm::sroa::SROALegacyPass::runOnFunction(llvm::Function&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x22B78D9: llvm::FPPassManager::runOnFunction(llvm::Function&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==  Address 0x5a5a5a5a5a5a5a62 is not stack'd, malloc'd or (recently) free'd
==1793==
pid 1793 (memcheck-amd64-free): sigreturn rflags = 0x4
==1793==
==1793== Process terminating with default action of signal 10 (SIGBUS): dumping core
==1793==  Hardware error at address 0x40F7A495F
==1793==    at 0x227C9BE: llvm::ValueHandleBase::AddToUseList() (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x29A3F2D: llvm::AssumptionCache::AffectedValueCallbackVH::allUsesReplacedWith(llvm::Value*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x227A884: llvm::ValueHandleBase::ValueIsRAUWd(llvm::Value*, llvm::Value*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x227A504: llvm::Value::doRAUW(llvm::Value*, bool) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x1C9791E: llvm::sroa::AllocaSliceRewriter::visitLoadInst(llvm::LoadInst&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x1C880FD: llvm::sroa::AllocaSliceRewriter::visit((anonymous namespace)::Slice const*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x1C86C9A: llvm::SROA::rewritePartition(llvm::AllocaInst&, llvm::sroa::AllocaSlices&, llvm::sroa::Partition&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x1C88584: llvm::SROA::splitAlloca(llvm::AllocaInst&, llvm::sroa::AllocaSlices&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x1C89A1D: llvm::SROA::runOnAlloca(llvm::AllocaInst&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x1C8B309: llvm::SROA::runImpl(llvm::Function&, llvm::DominatorTree&, llvm::AssumptionCache&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x1C9C239: llvm::sroa::SROALegacyPass::runOnFunction(llvm::Function&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
==1793==    by 0x22B78D9: llvm::FPPassManager::runOnFunction(llvm::Function&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
Comment 5 Dimitry Andric freebsd_committer 2017-01-15 23:03:40 UTC
I managed to figure out that upstream https://reviews.llvm.org/rL291671 caused a use-after-free issue, which is why it doesn't always crash.  I had to run it under valgrind to see relatively clearly where it came from.

Hal Finkel has put up a review for a fix here: https://reviews.llvm.org/D28749
Comment 6 commit-hook freebsd_committer 2017-01-16 19:53:57 UTC
A commit references this bug:

Author: dim
Date: Mon Jan 16 19:53:19 UTC 2017
New revision: 312308
URL: https://svnweb.freebsd.org/changeset/base/312308

Log:
  Pull in r292133 from upstream llvm trunk (by Hal Finkel):

    Fix use-after-free bug in AffectedValueCallbackVH::allUsesReplacedWith

    When transferring affected values in the cache from an old value,
    identified by the value of the current callback, to the specified new
    value we might need to insert a new entry into the DenseMap which
    constitutes the cache. Doing so might delete the current callback
    object. Move the copying logic into a new function, a member of the
    assumption cache itself, so that we don't run into UB should the
    callback handle itself be removed mid-copy.

    Differential Revision: https://reviews.llvm.org/D28749

  This should fix crashes when building lld (as part of the llvmXY ports).

  Reported by:	jbeich
  PR:		216117

Changes:
  projects/clang400-import/contrib/llvm/include/llvm/Analysis/AssumptionCache.h
  projects/clang400-import/contrib/llvm/lib/Analysis/AssumptionCache.cpp
Comment 7 Dimitry Andric freebsd_committer 2017-01-16 19:54:46 UTC
Should be fixed now, as of r312308.