Bug 97887 - llvm segfault in janusvr -render vive
Summary: llvm segfault in janusvr -render vive
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
Depends on:
Reported: 2016-09-21 11:24 UTC by Christoph Haag
Modified: 2016-10-07 16:07 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

stderr output with R600_DEBUG=vs,tcs,tes,gs,ps,cs (161.21 KB, text/plain)
2016-09-21 11:24 UTC, Christoph Haag
gdb.txt assertion with full backtrace (47.59 KB, text/plain)
2016-09-21 16:04 UTC, Christoph Haag

Description Christoph Haag 2016-09-21 11:24:38 UTC
Created attachment 126700 [details]
stderr output with R600_DEBUG=vs,tcs,tes,gs,ps,cs

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 480] (rev c7)
mesa git, linux drm-next-4.9-wip, llvm 4.0.0svn_r282018

So I'm trying to start janusvr -render vive with the steamvr-osvr steamvr plugin. Because osvr-rendermanager still doesn't do core profile, I start it with


But llvm segfaults:

Thread 12 "si_shader:1" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc3568700 (LWP 28734)]
0x00007fffc59ee0c6 in llvm::SSAUpdaterImpl<llvm::SSAUpdater>::BuildBlockList(llvm::BasicBlock*, llvm::SmallVectorImpl<llvm::SSAUpdaterImpl<llvm::SSAUpdater>::BBInfo*>*) () from /usr/lib/libLLVM-4.0svn.so
#0  0x00007fffc59ee0c6 in llvm::SSAUpdaterImpl<llvm::SSAUpdater>::BuildBlockList(llvm::BasicBlock*, llvm::SmallVectorImpl<llvm::SSAUpdaterImpl<llvm::SSAUpdater>::BBInfo*>*) () at /usr/lib/libLLVM-4.0svn.so
#1  0x00007fffc59f2acf in llvm::SSAUpdater::GetValueAtEndOfBlockInternal(llvm::BasicBlock*) () at /usr/lib/libLLVM-4.0svn.so
#2  0x00007fffc59f942a in llvm::SSAUpdater::RewriteUseAfterInsertions(llvm::Use&) () at /usr/lib/libLLVM-4.0svn.so
#3  0x00007fffc5cb7551 in (anonymous namespace)::StructurizeCFG::runOnRegion(llvm::Region*, llvm::RGPassManager&) () at /usr/lib/libLLVM-4.0svn.so
#4  0x00007fffc5f3571c in llvm::RGPassManager::runOnFunction(llvm::Function&) () at /usr/lib/libLLVM-4.0svn.so
#5  0x00007fffc53c03a2 in llvm::FPPassManager::runOnFunction(llvm::Function&) () at /usr/lib/libLLVM-4.0svn.so
#6  0x00007fffc53c0443 in llvm::FPPassManager::runOnModule(llvm::Module&) () at /usr/lib/libLLVM-4.0svn.so
#7  0x00007fffc53c0a54 in llvm::legacy::PassManagerImpl::run(llvm::Module&) () at /usr/lib/libLLVM-4.0svn.so
#8  0x00007fffc61a5d57 in LLVMTargetMachineEmit(LLVMOpaqueTargetMachine*, LLVMOpaqueModule*, llvm::raw_pwrite_stream&, LLVMCodeGenFileType, char**) () at /usr/lib/libLLVM-4.0svn.so
#9  0x00007fffc61a6139 in LLVMTargetMachineEmitToMemoryBuffer () at /usr/lib/libLLVM-4.0svn.so
#10 0x00007fffc889e7c3 in  () at /usr/lib/xorg/modules/dri/radeonsi_dri.so
#11 0x00007fffc8814605 in  () at /usr/lib/xorg/modules/dri/radeonsi_dri.so
#12 0x00007fffc88161d2 in  () at /usr/lib/xorg/modules/dri/radeonsi_dri.so
#13 0x00007fffc8822f73 in  () at /usr/lib/xorg/modules/dri/radeonsi_dri.so
#14 0x00007fffc868ec34 in  () at /usr/lib/xorg/modules/dri/radeonsi_dri.so
#15 0x00007fffc868e9f6 in  () at /usr/lib/xorg/modules/dri/radeonsi_dri.so
#16 0x00007ffff2636454 in start_thread () at /usr/lib/libpthread.so.0
#17 0x00007ffff1ad67df in clone () at /usr/lib/libc.so.6
Comment 1 Christoph Haag 2016-09-21 16:04:54 UTC
Created attachment 126706 [details]
gdb.txt assertion with full backtrace

With full debugging llvm and mesa I get an assertion instead:

janusvr: /home/chris/build/llvm-svn/src/llvm/include/llvm/Analysis/LoopInfoImpl.h:247: void llvm::LoopBase<N, M>::verifyLoop() const [with BlockT = llvm::BasicBlock; LoopT = llvm::Loop]: Assertion `std::any_of(GraphTraits<BlockT*>::child_begin(BB), GraphTraits<BlockT*>::child_end(BB), [&](BlockT *B){return contains(B);}) && "Loop block has no in-loop successors!"' failed.

backtrace full attached
Comment 2 Nicolai Hähnle 2016-09-28 12:06:07 UTC
I can reproduce this running plain JanusVR, and I'm going to investigate. Looks like there are actually two bugs - the one you originally reported, and another that prevents proper dumping of the affected shader.
Comment 3 Nicolai Hähnle 2016-10-07 16:07:27 UTC
This should be fixed in Mesa master now (commit 6f87d7a14699277be6dd17e9e712841c4057c4df).

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.