I can confirm the same error with Deadfall Adventures on the current git version of Mesa with LLVM 3.4.

The error is the same, I will try to provide a backtrace later today and maybe Leszek can also get his hands on some Steam keys for Deadfall for the Mesa developers.

Should I open a new report for Deadfall or can we assume this is the same bug?

Are you using the released version of LLVM 3.4 or an older git snapshot?  If you are using the released version of LLVM 3.4, can you run the game with the environment variable: R600_DEBUG=ps,vs and post the output?

I'm using the release version of LLVM 3.4 and ran the game with your debug option:

'R600_DEBUG=ps,vs ./ADVGame.sh > ADVGame_R600_DEBUG.log 1>&2'

Since I could not upload the file here (to big) I stored it on my server: http://shadowice.org/~flocke/linux/misc/ADVGame_R600_DEBUG.log

I hope this helps a little, I can try to provide additional information if needed.

I'm experiencing the same crash but with Deadfall Adventures. A Farm51 and Nordic games are the same people who made PKHD. I have the entire terminal output from launching the game here: http://pastebin.com/5GqDnYjQ

I was using Xubuntu 13.10 with a 3.13 kernel and this PPA for the graphics drivers. https://launchpad.net/~oibaf/+archive/graphics-drivers

System info per steam:Processor Information:
    Vendor:  AuthenticAMD
    CPU Family:  0x12
    CPU Model:  0x1
    CPU Stepping:  0x0
    CPU Type:  0x0
    Speed:  2999 Mhz
    4 logical processors
    4 physical processors
    HyperThreading:  Unsupported
    FCMOV:  Supported
    SSE2:  Supported
    SSE3:  Supported
    SSSE3:  Unsupported
    SSE4a:  Supported
    SSE41:  Unsupported
    SSE42:  Unsupported
    
Network Information:
    Network Speed:  
    
Operating System Version:
    Ubuntu 13.10 (64 bit)
    Kernel Name:  Linux
    Kernel Version:  3.13.0-031300-generic
    X Server Vendor:  The X.Org Foundation
    X Server Release:  11405000
    X Window Manager:  Xfwm4
    Steam Runtime Version:  steam-runtime-release_2013-10-23
    
Video Card:
    Driver:  X.Org Gallium oibaf PPA

    Driver Version:  oibaf PPA
    OpenGL Version: oibaf PPA
    Desktop Color Depth: 24 bits per pixel
    Monitor Refresh Rate: 59 Hz
    VendorID:  0x1002
    DeviceID:  0x683d
    Number of Monitors:  1
    Number of Logical Video Cards:  1
    Primary Display Resolution:  1680 x 1050
    Desktop Resolution: 1680 x 1050
    Primary Display Size: 18.66" x 11.65"  (21.97" diag)
                                            47.4cm x 29.6cm  (55.8cm diag)
    Primary VRAM Not Detected
    
Sound card:
    Audio device: Realtek ALC892
    
Memory:
    RAM:  7977 Mb
    
Miscellaneous:
    UI Language:  English
    LANG:  en_US.UTF-8
    Microphone:  Not set
    Total Hard Disk Space Available:  413941 Mb
    Largest Free Hard Disk Block:  385886 Mb

sorry, i thought steam info would've listed my model gpu but i notice now it didn't. I have an XFX HD7770 Black Edition

I will gladly provide free Steam keys for both Painkiller Hell & Damnation and Deadfall Adventures for developers who step up and try to tackle this! Just shoot me an email at the address I'm posting this from!

I am getting the same error with LLVM 3.4, Mesa Git and using radeonsi when I try running 3D Mark 2000 under wine.

Same "LLVM ERROR: ran out of registers during register allocation" here when running Brutal Legend from Steam.  The crash doesn't happen until part way through the loading screen when loading a save.  Works fine in the main menus.  This game was working before when I had an nvidia gtx260 card, but crashes now that I have switched to radeon hd 7850.  

Software:
Kernel 3.13.6
Mesa 10.0.3
Xen 4.3.1 (running under dom0)

Hardware:
Intel i7 3770
AMD Radeon HD 7850: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn PRO [Radeon HD 7850]

I will upgrade to the latest versions available in Arch this weekend to see if mesa 10.1 / linux 3.13 fixes it.  If not, I'll attempt git versions.

Sorry, that was kernel 3.12.6, not 3.13.6

(In reply to comment #8)
> Same "LLVM ERROR: ran out of registers during register allocation" here when
> running Brutal Legend from Steam.  The crash doesn't happen until part way
> through the loading screen when loading a save.  Works fine in the main
> menus.  This game was working before when I had an nvidia gtx260 card, but
> crashes now that I have switched to radeon hd 7850.  
> 
> Software:
> Kernel 3.13.6
> Mesa 10.0.3
> Xen 4.3.1 (running under dom0)
> 
> Hardware:
> Intel i7 3770
> AMD Radeon HD 7850: 01:00.0 VGA compatible controller: Advanced Micro
> Devices, Inc. [AMD/ATI] Pitcairn PRO [Radeon HD 7850]
> 
> I will upgrade to the latest versions available in Arch this weekend to see
> if mesa 10.1 / linux 3.13 fixes it.  If not, I'll attempt git versions.

Got the same on Arch with linux 3.13 and mesa-git from aur. Installing from aur llvm-svn and lib32-llvm-snv fixed this problem. My card is Radeon R9 270X 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn [1002:6810].

Can you try this patch: https://bugs.freedesktop.org/attachment.cgi?id=94675

I tried your patch with the newest SVN version of LLVM but got a different error (http://shadowice.org/~flocke/linux/misc/ADVGame_crash_backtrace.log).

Can I safely apply your patch to LLVM 3.4 to find out if the error comes from the SVN version?

(In reply to comment #12)
> I tried your patch with the newest SVN version of LLVM but got a different
> error (http://shadowice.org/~flocke/linux/misc/ADVGame_crash_backtrace.log).
> 
> Can I safely apply your patch to LLVM 3.4 to find out if the error comes
> from the SVN version?

Can you post the output of R600_DEBUG=ps,vs with the patch applied?

This is the log for the patched LLVM (SVN) with R600_DEBUG=ps,vs enabled: http://shadowice.org/~flocke/linux/misc/ADVGame_R600_DEBUG_patched.log

(In reply to comment #11)
> Can you try this patch: https://bugs.freedesktop.org/attachment.cgi?id=94675

I didn't try this patch, but I did build LLVM from svn (202114) and mesa from git (61630).  Also upgraded my kernel to 3.13.5.  Brutal Legend runs now, and seems to work fine.  Performance is pretty good too.

The patch doesnt apply cleanly to llvm 3.4 nor to the git master of llvm.
I also had trouble rebuilding mesa git master when I switched to llvm git master to try without the patch first.

I found 2 more occurences of the error.
The first one is random crashes in Antichamber.
The 2nd is a crash near the beginning of the Syberia game running under wine.

Can you try this branch:

http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes

On the first try the game didn't crash immediately but caused a GPU lockup before the title-screen appeared.
I will try to debug it later today.

(In reply to comment #17)
> Can you try this branch:
> 
> http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes

I cannot compile your repo with current clang git repo checked out in tools.
Not sure if I am doing something wrong here or something else is.

Heres the first part of the error message:

In file included from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20:0,
                 from HeaderMap.cpp:16:
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:98:57: error: expected template-name before ‘<’ token
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:98:57: error: expected ‘{’ before ‘<’ token
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:98:57: error: expected unqualified-id before ‘<’ token
In file included from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20:0,
                 from HeaderMap.cpp:16:
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:130:34: error: invalid use of incomplete type ‘class clang::vfs::FileSystem’
In file included from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20:0,
                 from HeaderMap.cpp:16:
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:98:7: error: forward declaration of ‘class clang::vfs::FileSystem’
In file included from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20:0,
                 from HeaderMap.cpp:16:
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:150:25: error: ‘llvm::ErrorOr<clang::vfs::Status> clang::vfs::OverlayFileSystem::status(const llvm::Twine&)’ marked override, but does not override
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:151:20: error: ‘llvm::error_code clang::vfs::OverlayFileSystem::openFileForRead(const llvm::Twine&, llvm::OwningPtr<clang::vfs::File>&)’ marked override, but does not override
In file included from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:17:0,
                 from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20,
                 from HeaderMap.cpp:16:
/home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h: In instantiation of ‘static void llvm::IntrusiveRefCntPtrInfo<T>::release(T*) [with T = clang::vfs::FileSystem]’:
/home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:176:31:   required from ‘void llvm::IntrusiveRefCntPtr<T>::release() [with T = clang::vfs::FileSystem]’
/home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:146:29:   required from ‘llvm::IntrusiveRefCntPtr<T>::~IntrusiveRefCntPtr() [with T = clang::vfs::FileSystem]’
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:166:78:   required from here
/home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:89:35: error: invalid use of incomplete type ‘class clang::vfs::FileSystem’
In file included from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20:0,
                 from HeaderMap.cpp:16:
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:98:7: error: forward declaration of ‘class clang::vfs::FileSystem’
In file included from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:17:0,
                 from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20,
                 from HeaderMap.cpp:16:
/home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h: In instantiation of ‘static void llvm::IntrusiveRefCntPtrInfo<T>::retain(T*) [with T = clang::vfs::FileSystem]’:
/home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:175:30:   required from ‘void llvm::IntrusiveRefCntPtr<T>::retain() [with T = clang::vfs::FileSystem]’
/home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:123:7:   required from ‘llvm::IntrusiveRefCntPtr<T>::IntrusiveRefCntPtr(const llvm::IntrusiveRefCntPtr<T>&) [with T = clang::vfs::FileSystem; llvm::IntrusiveRefCntPtr<T> = llvm::IntrusiveRefCntPtr<clang::vfs::FileSystem>]’
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:231:12:   required from here
/home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:88:34: error: invalid use of incomplete type ‘class clang::vfs::FileSystem’
In file included from /home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20:0,
                 from HeaderMap.cpp:16:
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:98:7: error: forward declaration of ‘class clang::vfs::FileSystem’

You don't need clang for graphics, so you can remove it from the tools directory.  If you do want to build clang for some reason you need to make sure your checkout of clang is from roughly the same date and time as the LLVM checkout you are using.

I amanaged to build llvm and mesa.

Here's my test results:
As for both wine applications 3D Mark 2000 and Syberia, the error is gone and both applications continue past normally.

But Antichamber will crash the system hard.
I have found place in the game where the llvm error always happens.
When I use your version of llvm 3.5 instead of llvm 3.4 Antichamber wont exit with the error it will instead deadlock the whole system, only option is reboot.

I'm also getting this same error when trying to run Diablo III: Reaper of Souls via Wine. My setup is identical to ubu's with the only differences being that I'm using Netrunner (KDE) and that my graphics card is a HD 7750. When running the game, it consistently crashes after retrieving the character list with the "LLVM runs out of registers" error.

(In reply to comment #22)
> I'm also getting this same error when trying to run Diablo III: Reaper of
> Souls via Wine. My setup is identical to ubu's with the only differences
> being that I'm using Netrunner (KDE) and that my graphics card is a HD 7750.
> When running the game, it consistently crashes after retrieving the
> character list with the "LLVM runs out of registers" error.

Can also confirm a similar scenario with Diablo III (using Radeon HD 7850, Kernel 3.14.0-999-generic #201404020331, Xubuntu 14.04, oibaf's PPA, Wine 1.7.15).

DId yo(In reply to comment #21)
> I amanaged to build llvm and mesa.
> 
> Here's my test results:
> As for both wine applications 3D Mark 2000 and Syberia, the error is gone
> and both applications continue past normally.
> 
> But Antichamber will crash the system hard.
> I have found place in the game where the llvm error always happens.
> When I use your version of llvm 3.5 instead of llvm 3.4 Antichamber wont
> exit with the error it will instead deadlock the whole system, only option
> is reboot.

Did you try this branch: http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes

(In reply to comment #24)
> DId yo(In reply to comment #21)
> > I amanaged to build llvm and mesa.
> > 
> > Here's my test results:
> > As for both wine applications 3D Mark 2000 and Syberia, the error is gone
> > and both applications continue past normally.
> > 
> > But Antichamber will crash the system hard.
> > I have found place in the game where the llvm error always happens.
> > When I use your version of llvm 3.5 instead of llvm 3.4 Antichamber wont
> > exit with the error it will instead deadlock the whole system, only option
> > is reboot.
> 
> Did you try this branch:
> http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes

~/workspace/llvm $ git --no-pager log -1
commit 14e6c5b9e0a0bf05afcaf4f1154f0cf82c4b5fd2
Author: Tom Stellard <thomas.stellard@amd.com>
Date:   Mon Mar 3 14:27:38 2014 -0500

    R600/SI: Implement VGPR register spilling
    
    VGPRs are spilled to LDS.

Antichamber doesnt crash right away.
When it happens it looks to me like the graphics card became very very busy suddenly.
Then the screen goes black like it doesnt get a signal anymore.
After that it crashes.

Like I said in my last comment, with your branch the GPU locks up after a (very) short while.
I don't have time at the moment (final exams), but I will try to debug it as soon as I get the time (maybe in 4 weeks), if it isn't fixed until then.

Created attachment 97521 [details] [review]
Work around for crash

Hi can you try this LLVM patch.  You will need to apply it on top of the very latest LLVM tree and also use the latest Mesa from git.

You will likely experience mis-rendering with this patch, but hopefully the crash and hang will be gone.

Created attachment 97522 [details] [review]
Work Around

Sorry, I posted the wrong patch before.  Try this one.

Patch doesnt compile:
SIInstrInfo.cpp:198:41: error: invalid use of incomplete type ‘const class llvm::Function’

Created attachment 97539 [details] [review]
Work around v2

This one should compile.

LLVM triggered Diagnostic Handler: SIInstrInfo::storeRegToStackSlot - Can't spill VGPR!
<several times the above message>
./Antichamber.sh: line 3:  3074 Segmentation fault      ./UDKGame-Linux $@

Crash is gone.

(In reply to comment #31)
> LLVM triggered Diagnostic Handler: SIInstrInfo::storeRegToStackSlot - Can't
> spill VGPR!
> <several times the above message>
> ./Antichamber.sh: line 3:  3074 Segmentation fault      ./UDKGame-Linux $@
> 
> Crash is gone.

The crash is gone, but you are now seeing a segfault?  Can you get a backtrace?

Program received signal SIGSEGV, Segmentation fault.
0xf4ba33e1 in llvm::SIInstrInfo::copyPhysReg (this=0x43f6b140, MBB=..., MI=..., DL=..., DestReg=0, SrcReg=106, KillSrc=true)
    at SIInstrInfo.cpp:160
160       while (unsigned SubIdx = *SubIndices++) {
(gdb) bt
#0  0xf4ba33e1 in llvm::SIInstrInfo::copyPhysReg (this=0x43f6b140, MBB=..., MI=..., DL=..., DestReg=0, SrcReg=106, KillSrc=true)
    at SIInstrInfo.cpp:160
#1  0xf50766b8 in (anonymous namespace)::ExpandPostRA::LowerCopy (this=0x44b60e00, MI=0x45013d20) at ExpandPostRAPseudos.cpp:165
#2  0xf50768b3 in (anonymous namespace)::ExpandPostRA::runOnMachineFunction (this=0x44b60e00, MF=...) at ExpandPostRAPseudos.cpp:213
#3  0xf50f264f in llvm::MachineFunctionPass::runOnFunction (this=0x44b60e00, F=...) at MachineFunctionPass.cpp:33
#4  0xf4dc053f in llvm::FPPassManager::runOnFunction (this=0x446590c0, F=...) at LegacyPassManager.cpp:1540
#5  0xf4dc06e0 in llvm::FPPassManager::runOnModule (this=0x446590c0, M=...) at LegacyPassManager.cpp:1560
#6  0xf4dc09e4 in (anonymous namespace)::MPPassManager::runOnModule (this=0x431b3380, M=...) at LegacyPassManager.cpp:1618
#7  0xf4dc0f53 in llvm::legacy::PassManagerImpl::run (this=0x44803000, M=...) at LegacyPassManager.cpp:1725
#8  0xf4dc1147 in llvm::legacy::PassManager::run (this=0xffff6b08, M=...) at LegacyPassManager.cpp:1760
#9  0xf5291a59 in LLVMTargetMachineEmit (T=0x44d746c0, M=0x445881c0, OS=..., codegen=LLVMObjectFile, ErrorMessage=0xffff6be8)
    at TargetMachineC.cpp:233
#10 0xf5291bed in LLVMTargetMachineEmitToMemoryBuffer (T=0x44d746c0, M=0x445881c0, codegen=LLVMObjectFile, ErrorMessage=0xffff6be8, 
    OutMemBuf=0xffff6be0) at TargetMachineC.cpp:259
#11 0xf5bab1f8 in radeon_llvm_compile (M=0x445881c0, binary=0xffff6c70, gpu_family=0xf5fb96f1 "verde", dump=0) at radeon_llvm_emit.c:148
#12 0xf5b8c7d5 in si_compile_llvm (sctx=0xc148100, shader=0x44db9800, mod=0x445881c0) at si_shader.c:2306
#13 0xf5b8d448 in si_pipe_shader_create (ctx=0xc148100, shader=0x44db9800) at si_shader.c:2583
#14 0xf5b92660 in si_shader_select (ctx=0xc148100, sel=0x448adc80) at si_state.c:2114
#15 0xf5b9279f in si_create_shader_state (ctx=0xc148100, state=0x43f6b508, pipe_shader_type=1) at si_state.c:2146
#16 0xf5b927e8 in si_create_fs_state (ctx=0xc148100, state=0x43f6b508) at si_state.c:2158
#17 0xf5da395a in st_translate_fragment_program (st=0xbf90000, stfp=0x44c01680, key=0xffffb970) at state_tracker/st_program.c:782
#18 0xf5da3a55 in st_get_fp_variant (st=0xbf90000, stfp=0x44c01680, key=0xffffb970) at state_tracker/st_program.c:819
#19 0xf5d60b4b in update_fp (st=0xbf90000) at state_tracker/st_atom_shader.c:92
#20 0xf5d5b80d in st_validate_state (st=0xbf90000) at state_tracker/st_atom.c:212
#21 0xf5d7b220 in st_draw_vbo (ctx=0xcf2f000, prims=0xffffbb1c, nr_prims=1, ib=0xffffbb38, index_bounds_valid=1 '\001', min_index=0, 
    max_index=4, tfb_vertcount=0x0, indirect=0x0) at state_tracker/st_draw.c:198
#22 0xf5d3aadf in vbo_handle_primitive_restart (ctx=0xcf2f000, prim=0xffffbb1c, nr_prims=1, ib=0xffffbb38, index_bounds_valid=1 '\001', 
    min_index=0, max_index=4) at vbo/vbo_exec_array.c:591
#23 0xf5d3b6a5 in vbo_validated_drawrangeelements (ctx=0xcf2f000, mode=4, index_bounds_valid=1 '\001', start=0, end=4, count=6, type=5123, 
    indices=0x949d904 <DrawDenormalizedQuad(float, float, float, float, float, float, float, float, unsigned int, unsigned int, unsigned int, unsigned int, float)::Indices>, basevertex=0, numInstances=1, baseInstance=0) at vbo/vbo_exec_array.c:1014
#24 0xf5d3b90e in vbo_exec_DrawRangeElementsBaseVertex (mode=4, start=0, end=4, count=6, type=5123, 
    indices=0x949d904 <DrawDenormalizedQuad(float, float, float, float, float, float, float, float, unsigned int, unsigned int, unsigned int, unsigned int, float)::Indices>, basevertex=0) at vbo/vbo_exec_array.c:1122
#25 0xf5d3b9cf in vbo_exec_DrawRangeElements (mode=4, start=0, end=4, count=6, type=5123, 
---Type <return> to continue, or q <return> to quit---
    indices=0x949d904 <DrawDenormalizedQuad(float, float, float, float, float, float, float, float, unsigned int, unsigned int, unsigned int, unsigned int, float)::Indices>) at vbo/vbo_exec_array.c:1142
#26 0x08baac6b in RHIDrawIndexedPrimitiveUP (VertexDataStride=32, VertexData=0xffffbc40, IndexDataStride=2, 
    IndexData=0x949d904 <DrawDenormalizedQuad(float, float, float, float, float, float, float, float, unsigned int, unsigned int, unsigned int, unsigned int, float)::Indices>, NumPrimitives=2, NumVertices=4, MinVertexIndex=0, PrimitiveType=0)
    at ../../Development/Src/Engine/Inc/RHIMethods.h:1658
#27 DrawDenormalizedQuad (X=0, Y=0, SizeX=420, SizeY=247, U=0, V=0, SizeU=420, SizeV=247, TargetSizeX=TargetSizeX@entry=422, 
    TargetSizeY=258, TextureSizeX=TextureSizeX@entry=422, TextureSizeY=258, ClipSpaceQuadZ=ClipSpaceQuadZ@entry=0)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneFilterRendering.cpp:199
#28 0x08b76416 in ApplyRadialBlur (SourceFilterBuffer=SRTI_FilterColor1, DestFilterBuffer=SRTI_FilterColor0, BlurVectorScale=1, 
    LightSceneInfo=0x42a63c00, View=...)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/LightShaftRendering.cpp:872
#29 FSceneRenderer::RenderLightShafts (this=this@entry=0x44d3c900)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/LightShaftRendering.cpp:1113
#30 0x08bb6500 in FSceneRenderer::RenderDPGEnd (this=this@entry=0x44d3c900, DPGIndex=DPGIndex@entry=1, 
    bDeferPrePostProcessResolve=bDeferPrePostProcessResolve@entry=1, bSceneColorDirty=@0xffffbf80: 1, bIsOcclusionTesting=1)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:2194
#31 0x08bc15ee in FSceneRenderer::Render (this=this@entry=0x44d3c900)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:2670
#32 0x08bc16c4 in RenderViewFamily_RenderThread (SceneRenderer=SceneRenderer@entry=0x44d3c900)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:4166
#33 0x08bc1877 in Execute (this=<synthetic pointer>)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:4381
#34 BeginRenderingViewFamily (Canvas=0xffffc6a4, ViewFamily=0xffffc4f0)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:4381
#35 0x0882652e in UGameViewportClient::Draw (this=0xbf14700, Viewport=0xa03bb44, Canvas=0xffffc6a4)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/UnPlayer.cpp:1081
#36 0x08564935 in FViewport::Draw (this=0xa03bb44, bShouldPresent=bShouldPresent@entry=1)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/UnClient.cpp:823
#37 0x08643249 in UGameEngine::RedrawViewports (this=0xb20e800, bShouldPresent=1)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/UnGame.cpp:76
#38 0x08649ae5 in UGameEngine::Tick (this=0xb20e800, DeltaSeconds=0.0317840576)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/UnGame.cpp:4249
#39 0x08e7b6a2 in FEngineLoop::Tick (this=this@entry=0x95c6900 <GEngineLoop>)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Launch/Src/LaunchEngineLoop.cpp:3970
---Type <return> to continue, or q <return> to quit---
#40 0x08e8328c in EngineTick ()
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Launch/Src/Launch.cpp:193
#41 GuardedMain (CmdLine=0x90cfaf0 L"", hInInstance=hInInstance@entry=0x0, hPrevInstance=hPrevInstance@entry=0x0, 
    nCmdShow=nCmdShow@entry=0)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Launch/Src/Launch.cpp:290
#42 0x08e37f7d in main (argc=1, argv=0xffffcbd4)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Linux/Src/Linux.cpp:727

Unfortunately, most of the games are affected by this bug. I'm running on HD7850 and get this error on Metro, Serious Sam 3, Xonotic (with Ultra settings), whole bunch of games on Wine (tested with Risen, Star Wars: Republic Commando and others). There are almost no (modern) games which are running currently on radeionSI.
I'm using ArchLinux with Kernel 3.14.1, LLVM 3.4 everything's updated from the repos to the most recent version. Don't really want to go back to catalyst, so how can I help?

Can you test this branch:
http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes-v2

Updated v3 branch here:
http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes-v3

Hi,

I'm new to this and doing something wrong. Do I need to compile the patched LLVM and the latest Mesa from git? Or is it sufficient to recompile Mesa 10.1.... also not quite sure, how to force my system to use the modified stuf without breaking things.

(In reply to comment #37)
> Hi,
> 
> I'm new to this and doing something wrong. Do I need to compile the patched
> LLVM and the latest Mesa from git? Or is it sufficient to recompile Mesa
> 10.1.... also not quite sure, how to force my system to use the modified
> stuf without breaking things.

I would recommend using the LLVM branch plus the latest Mesa code from git.  To avoid breaking your current system, you can install LLVM to a non-standard path and then pass the --with-llvm-prefix=/path/to/llvm to mesa's configure script.

I've double and triple checked to make sure I am making no mistake but the behaviour I see with Antichamber and the v2 and v3 branches is the same as reported in comment 21.

I confirm this bug is a case for me on Radeon 7870 and Xonotic with highest details only. High details run fine. Using Arch Linux (mesa 10.1.1, llvm 3.4).

@filipp.andjelo@gmail.com Since you are using Arch too, would you mind writing a PKGBUILD that would include all the patches that we need to test? I'd love to help and test the patches out, but I'd rather stay away from digging into how to compile these things. ;-)

Hi Damian,

unfortunately, I didn't have enough time to build appropriate packages. I built patched LLVM manually and modified mesa package from Arch repository to use my LLVM. Nevertheless, it doesn't work yet as expected. I need more time to figure out, what went wrong... when I'm done, I will probably be able to supply PKGBUILD for you...

I just can't get it running. LLVM + mesa is compiled, but as far as I install and restart it, my system falls back to swrast and that's all.... as I said, I'm not familiar with mesa/llvm development and just don't know what's wrong...

Hi, I still would like to help. Can somebody post a short howto build everything to test the patched code? I'd like to know, what is required aside of LLVM and Mesa? Where can I see some logs about what is failing... such things.
Furthermore, shouldn't the importance of this bug raised? I mean with current state radeonsi is unusable for almost 90% of applications.... If you look at openbenchmarking.org, you will only find some low quality tests, but all the interesting stuff is broken.

Hres a short howto that I use to test this stuff:

Build llvm from a repo:
(change the prefix to where you want the have this installed, the configure is setup for a 32bit build to test with wine and Antichamber)

the main llvm url is http://llvm.org/git/llvm
tom stellar's repo is at git://people.freedesktop.org/~tstellar/llvm

git clone <llvm repo url>
cd llvm
git checkout <branch name>
./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --prefix=/home/eho/programs --enable-keep-symbols --enable-shared --disable-assertions --enable-libffi --enable-targets=host,cpp,r600
make -j5 install

Build mesa from git:
git clone git://anongit.freedesktop.org/mesa/mesa
cd mesa
/configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --prefix=/home/eho/programs --enable-glx --enable-shared-glapi --enable-texture-float --enable-egl --enable-gbm --enable-gles1 --enable-gles2 --enable-glx-tls --enable-osmesa --enable-asm --with-dri-drivers=swrast,radeon --with-gallium-drivers=swrast,radeonsi,r600 --with-egl-platforms=x11,wayland,drm --enable-gallium-llvm --enable-openvg --enable-gallium-egl --enable-dri --enable-xvmc --enable-dri3 --enable-vdpau --enable-r600-llvm-compiler --enable-debug
make -j5 install

To run your app you do:
export LD_LIBRARY_PATH=<your prefix>/lib (for me would be /home/eho/programs/lib)
<call your app here>

Does this help?

Thank you very much for your help farmboy0. I was able to build and run everything as you mentioned. First of all, my systems doesn't hang as you describe in Comment 21, all the games are (kind of) running.
I tested master branch of llvm as well as http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes-v3. Both versions don't crash anymore, but the performance is very bad. With master branch the games are stuttering heavily, every 2-3 seconds the application stops for a second. With the si-spill-fixes-v3 everything's running a bit smoother, but still very slowly. Feels like similar behavior in both cases, but using si-spill-fixes-v3 it feels like the games would "wait" for shorter period of time, therefor more often. I tested with both 64 and 32 bit builds.

(In reply to comment #45)
> Thank you very much for your help farmboy0. I was able to build and run
> everything as you mentioned. First of all, my systems doesn't hang as you
> describe in Comment 21, all the games are (kind of) running.
> I tested master branch of llvm as well as
> http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes-v3. Both
> versions don't crash anymore, but the performance is very bad. With master
> branch the games are stuttering heavily, every 2-3 seconds the application
> stops for a second. With the si-spill-fixes-v3 everything's running a bit
> smoother, but still very slowly. Feels like similar behavior in both cases,
> but using si-spill-fixes-v3 it feels like the games would "wait" for shorter
> period of time, therefor more often. I tested with both 64 and 32 bit builds.

You need to realize though that the error message of llvm running out of registers is caused by two seperate issues.

The first issue is caused by errors with the SGPR spilling in llvm 3.4, this one is fixed with llvm git or with Tom's si-spilling-fixes branch.

The second issue is recorded in https://bugs.freedesktop.org/show_bug.cgi?id=75276
 and is not yet fixed as (at least for me) it causes crashes.

You can differentiate the two issues while using llvm git. If while running your app you see messages in the console to the effect of VGPR spilling not being supported your app is hit by issue number two. You should then try to run this app with Tom's si-spill-fixes-v3 branch which started to try to implement VGPR spilling if i interpret the change messages correctly.

Ok, thank you for clarification. I know, that such statements doesn't really help to solve problems in any way, but my system doesn't crash or freeze and I also not see any messages, that the VGPR spilling is not supported...

(In reply to comment #47)
> Ok, thank you for clarification. I know, that such statements doesn't really
> help to solve problems in any way, but my system doesn't crash or freeze and
> I also not see any messages, that the VGPR spilling is not supported...

This means that your apps only had issue #1 and as i already said this one is fixed already.

My app OTOH has issue #2 and thus it cashes. If your apps had issue #2 as well but you wouldnt see any crashes that would be relevant.

Can you try this LLVM patch:

https://bugs.freedesktop.org/attachment.cgi?id=99169

This patch on top of llvm git master makes Antichamber segfault with the following backtrace:

Program received signal SIGSEGV, Segmentation fault.
0xf5054dd3 in std::pair<llvm::SlotIndex, llvm::SlotIndex>::operator= (this=0x44fd2ff4, __p=...)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4/bits/stl_pair.h:153
153             second = __p.second;
(gdb) bt
#0  0xf5054dd3 in std::pair<llvm::SlotIndex, llvm::SlotIndex>::operator= (this=0x44fd2ff4, __p=...)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4/bits/stl_pair.h:153
#1  0xf5064027 in llvm::IntervalMapImpl::NodeBase<std::pair<llvm::SlotIndex, llvm::SlotIndex>, llvm::LiveInterval*, 16u>::copy<16u> (
    this=0x44e14ef4, Other=..., i=228385, j=228384, Count=4294967295)
    at /mnt/daten/Daten/Repositories/llvm/include/llvm/ADT/IntervalMap.h:231
#2  0xf5064b0f in llvm::IntervalMapImpl::NodeBase<std::pair<llvm::SlotIndex, llvm::SlotIndex>, llvm::LiveInterval*, 16u>::moveLeft (
    this=0x44e14ef4, i=1, j=0, Count=4294967295) at /mnt/daten/Daten/Repositories/llvm/include/llvm/ADT/IntervalMap.h:242
#3  0xf50643e3 in llvm::IntervalMapImpl::NodeBase<std::pair<llvm::SlotIndex, llvm::SlotIndex>, llvm::LiveInterval*, 16u>::erase (
    this=0x44e14ef4, i=0, j=1, Size=0) at /mnt/daten/Daten/Repositories/llvm/include/llvm/ADT/IntervalMap.h:263
#4  0xf50638d7 in llvm::IntervalMapImpl::NodeBase<std::pair<llvm::SlotIndex, llvm::SlotIndex>, llvm::LiveInterval*, 16u>::erase (
    this=0x44e14ef4, i=0, Size=0) at /mnt/daten/Daten/Repositories/llvm/include/llvm/ADT/IntervalMap.h:270
#5  0xf5062950 in llvm::IntervalMap<llvm::SlotIndex, llvm::LiveInterval*, 16u, llvm::IntervalMapInfo<llvm::SlotIndex> >::iterator::erase (
    this=0xffff6338) at /mnt/daten/Daten/Repositories/llvm/include/llvm/ADT/IntervalMap.h:1876
#6  0xf5061fa8 in llvm::LiveIntervalUnion::extract (this=0x44e14ef0, VirtReg=...) at LiveIntervalUnion.cpp:68
#7  0xf506ad51 in llvm::LiveRegMatrix::unassign (this=0xbea0460, VirtReg=...) at LiveRegMatrix.cpp:96
#8  0xf5123ed7 in (anonymous namespace)::RAGreedy::tryLastChanceRecoloring (this=0x449f4000, VirtReg=..., Order=..., NewVRegs=..., 
    FixedRegisters=..., Depth=0) at RegAllocGreedy.cpp:2067
#9  0xf51248dc in (anonymous namespace)::RAGreedy::selectOrSplitImpl (this=0x449f4000, VirtReg=..., NewVRegs=..., FixedRegisters=..., 
    Depth=0) at RegAllocGreedy.cpp:2285
#10 0xf5124218 in (anonymous namespace)::RAGreedy::selectOrSplit (this=0x449f4000, VirtReg=..., NewVRegs=...) at RegAllocGreedy.cpp:2144
#11 0xf5116c4d in llvm::RegAllocBase::allocatePhysRegs (this=0x449f4010) at RegAllocBase.cpp:109
#12 0xf5124e05 in (anonymous namespace)::RAGreedy::runOnMachineFunction (this=0x449f4000, mf=...) at RegAllocGreedy.cpp:2343
#13 0xf50a614f in llvm::MachineFunctionPass::runOnFunction (this=0x449f4000, F=...) at MachineFunctionPass.cpp:33
#14 0xf4d6434c in llvm::FPPassManager::runOnFunction (this=0x43bd6180, F=...) at LegacyPassManager.cpp:1545
#15 0xf4d64528 in llvm::FPPassManager::runOnModule (this=0x43bd6180, M=...) at LegacyPassManager.cpp:1567
#16 0xf4d6482c in (anonymous namespace)::MPPassManager::runOnModule (this=0x4340b1c0, M=...) at LegacyPassManager.cpp:1625
#17 0xf4d64dcb in llvm::legacy::PassManagerImpl::run (this=0x439dce00, M=...) at LegacyPassManager.cpp:1734
#18 0xf4d64fbf in llvm::legacy::PassManager::run (this=0xffff6988, M=...) at LegacyPassManager.cpp:1769
#19 0xf524806d in LLVMTargetMachineEmit (T=0xa61eb40, M=0x43869540, OS=..., codegen=LLVMObjectFile, ErrorMessage=0xffff6a68)
    at TargetMachineC.cpp:234
#20 0xf5248201 in LLVMTargetMachineEmitToMemoryBuffer (T=0xa61eb40, M=0x43869540, codegen=LLVMObjectFile, ErrorMessage=0xffff6a68, 
    OutMemBuf=0xffff6a60) at TargetMachineC.cpp:260
#21 0xf5b91734 in radeon_llvm_compile (M=0x43869540, binary=0xffff6af0, gpu_family=0xf5fab3fd "verde", dump=0) at radeon_llvm_emit.c:148
#22 0xf5b72b17 in si_compile_llvm (sctx=0xc146100, shader=0x44b0c000, mod=0x43869540) at si_shader.c:2342
#23 0xf5b73811 in si_pipe_shader_create (ctx=0xc146100, shader=0x44b0c000) at si_shader.c:2622
---Type <return> to continue, or q <return> to quit--- 
#24 0xf5b78acf in si_shader_select (ctx=0xc146100, sel=0x4364e780) at si_state.c:2130
#25 0xf5b78c0e in si_create_shader_state (ctx=0xc146100, state=0x44afedc8, pipe_shader_type=1) at si_state.c:2162
#26 0xf5b78c57 in si_create_fs_state (ctx=0xc146100, state=0x44afedc8) at si_state.c:2174
#27 0xf5d939ae in st_translate_fragment_program (st=0xbf8b000, stfp=0x44c8d700, key=0xffffb8d0) at state_tracker/st_program.c:787
#28 0xf5d93aa9 in st_get_fp_variant (st=0xbf8b000, stfp=0x44c8d700, key=0xffffb8d0) at state_tracker/st_program.c:824
#29 0xf5d4f943 in update_fp (st=0xbf8b000) at state_tracker/st_atom_shader.c:92
#30 0xf5d4a421 in st_validate_state (st=0xbf8b000) at state_tracker/st_atom.c:213
#31 0xf5d6a224 in st_draw_vbo (ctx=0xc290000, prims=0xffffba7c, nr_prims=1, ib=0xffffba98, index_bounds_valid=1 '\001', min_index=0, 
    max_index=4, tfb_vertcount=0x0, indirect=0x0) at state_tracker/st_draw.c:198
#32 0xf5d2944f in vbo_handle_primitive_restart (ctx=0xc290000, prim=0xffffba7c, nr_prims=1, ib=0xffffba98, index_bounds_valid=1 '\001', 
    min_index=0, max_index=4) at vbo/vbo_exec_array.c:591
#33 0xf5d2a015 in vbo_validated_drawrangeelements (ctx=0xc290000, mode=4, index_bounds_valid=1 '\001', start=0, end=4, count=6, type=5123, 
    indices=0x949d904 <DrawDenormalizedQuad(float, float, float, float, float, float, float, float, unsigned int, unsigned int, unsigned int, unsigned int, float)::Indices>, basevertex=0, numInstances=1, baseInstance=0) at vbo/vbo_exec_array.c:1014
#34 0xf5d2a27e in vbo_exec_DrawRangeElementsBaseVertex (mode=4, start=0, end=4, count=6, type=5123, 
    indices=0x949d904 <DrawDenormalizedQuad(float, float, float, float, float, float, float, float, unsigned int, unsigned int, unsigned int, unsigned int, float)::Indices>, basevertex=0) at vbo/vbo_exec_array.c:1122
#35 0xf5d2a33f in vbo_exec_DrawRangeElements (mode=4, start=0, end=4, count=6, type=5123, 
    indices=0x949d904 <DrawDenormalizedQuad(float, float, float, float, float, float, float, float, unsigned int, unsigned int, unsigned int, unsigned int, float)::Indices>) at vbo/vbo_exec_array.c:1142
#36 0x08baac6b in RHIDrawIndexedPrimitiveUP (VertexDataStride=32, VertexData=0xffffbba0, IndexDataStride=2, 
    IndexData=0x949d904 <DrawDenormalizedQuad(float, float, float, float, float, float, float, float, unsigned int, unsigned int, unsigned int, unsigned int, float)::Indices>, NumPrimitives=2, NumVertices=4, MinVertexIndex=0, PrimitiveType=0)
    at ../../Development/Src/Engine/Inc/RHIMethods.h:1658
#37 DrawDenormalizedQuad (X=0, Y=0, SizeX=420, SizeY=247, U=0, V=0, SizeU=420, SizeV=247, TargetSizeX=TargetSizeX@entry=422, 
    TargetSizeY=258, TextureSizeX=TextureSizeX@entry=422, TextureSizeY=258, ClipSpaceQuadZ=ClipSpaceQuadZ@entry=0)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneFilterRendering.cpp:199
#38 0x08b76416 in ApplyRadialBlur (SourceFilterBuffer=SRTI_FilterColor1, DestFilterBuffer=SRTI_FilterColor0, BlurVectorScale=1, 
    LightSceneInfo=0x4307b000, View=...)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/LightShaftRendering.cpp:872
#39 FSceneRenderer::RenderLightShafts (this=this@entry=0x44affb00)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/LightShaftRendering.cpp:1113
#40 0x08bb6500 in FSceneRenderer::RenderDPGEnd (this=this@entry=0x44affb00, DPGIndex=DPGIndex@entry=1, 
    bDeferPrePostProcessResolve=bDeferPrePostProcessResolve@entry=1, bSceneColorDirty=@0xffffbee0: 1, bIsOcclusionTesting=1)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:2194
---Type <return> to continue, or q <return> to quit---
#41 0x08bc15ee in FSceneRenderer::Render (this=this@entry=0x44affb00)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:2670
#42 0x08bc16c4 in RenderViewFamily_RenderThread (SceneRenderer=SceneRenderer@entry=0x44affb00)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:4166
#43 0x08bc1877 in Execute (this=<synthetic pointer>)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:4381
#44 BeginRenderingViewFamily (Canvas=0xffffc604, ViewFamily=0xffffc450)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/SceneRendering.cpp:4381
#45 0x0882652e in UGameViewportClient::Draw (this=0xbf341c0, Viewport=0x9fb4c04, Canvas=0xffffc604)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/UnPlayer.cpp:1081
#46 0x08564935 in FViewport::Draw (this=0x9fb4c04, bShouldPresent=bShouldPresent@entry=1)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/UnClient.cpp:823
#47 0x08643249 in UGameEngine::RedrawViewports (this=0xb201800, bShouldPresent=1)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/UnGame.cpp:76
#48 0x08649ae5 in UGameEngine::Tick (this=0xb201800, DeltaSeconds=0.0484998226)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Engine/Src/UnGame.cpp:4249
#49 0x08e7b6a2 in FEngineLoop::Tick (this=this@entry=0x95c6900 <GEngineLoop>)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Launch/Src/LaunchEngineLoop.cpp:3970
#50 0x08e8328c in EngineTick ()
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Launch/Src/Launch.cpp:193
#51 GuardedMain (CmdLine=0x90cfaf0 L"", hInInstance=hInInstance@entry=0x0, hPrevInstance=hPrevInstance@entry=0x0, 
    nCmdShow=nCmdShow@entry=0)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Launch/Src/Launch.cpp:290
#52 0x08e37f7d in main (argc=1, argv=0xffffcb34)
    at /samba/ue3builds/DONKEY/projects/minority/UE3/Development/Src/../../Development/Src/Linux/Src/Linux.cpp:727

*** This bug has been marked as a duplicate of bug 75276 ***