I think this bug is unique to the x86 build of the game. I'm looking into it.

--ryan.

Same problem on linux Debian 7.

uname -a
Linux debian 3.2.0-4-686-pae #1 SMP Debian 3.2.60-1+deb7u3 i686 GNU/Linux

I try different video drivers versions
340.24 and 304.123 same result.
lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2)

Xorg -version

X.Org X Server 1.12.4
Release Date: 2012-08-27
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.2.0-4-amd64 i686 Debian
Current Operating System: Linux debian 3.2.0-4-686-pae #1 SMP Debian 3.2.60-1+deb7u3 i686
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-686-pae root=UUID=28e7de54-4196-4916-8c39-76d358610a67 ro quiet
Build Date: 17 December 2013  08:37:13PM
xorg-server 2:1.12.4-6+deb7u2 (Julien Cristau <jcristau@debian.org>)

When trying to hunt on the one crash bug that's nagging me, I tried the new x86 versino as well. I can confirm that it's stuck at the loading screen. Though the 3-dot-loading-animation is alive, it never seems to finish. So, attaching gdb reveals:

[Switching to thread 1 (Thread 0xf6ceea40 (LWP 10032))]
#0  0x09aea048 in Scaleform::Render::ContextImpl::Context::clearRTHandleList() ()
#1  0x09aea9d2 in Scaleform::Render::ContextImpl::Context::Shutdown(bool) ()
#2  0x09a9a089 in Scaleform::GFx::MovieImpl::~MovieImpl() ()
#3  0x09a9a990 in Scaleform::GFx::MovieImpl::~MovieImpl() ()
#4  0x09a8c634 in Scaleform::GFx::Movie::Release() ()
#5  0x096cb033 in FGFxEngine::DeleteQueuedMovies(unsigned int) ()
#6  0x096cb390 in FGFxEngine::NotifyGameSessionEnded() ()
#7  0x089aab1c in UObject::CallFunction(FFrame&, void*, UFunction*) ()
#8  0x089ab1d1 in UObject::execVirtualFunction(FFrame&, void*) ()
#9  0x089b0125 in UObject::execContext(FFrame&, void*) ()
#10 0x089aa9c9 in UObject::ProcessInternal(FFrame&, void*) ()
#11 0x089ab398 in UObject::ProcessEvent(UFunction*, void*, void*) ()
#12 0x09632312 in UWorld::CleanupWorld(unsigned int) ()
#13 0x091861fd in UGameEngine::LoadMap(FURL const&, UPendingLevel*, FString&) ()
#14 0x091849a3 in UGameEngine::Browse(FURL, FString&) ()
#15 0x0918a602 in UGameEngine::Tick(float) ()
#16 0x098eaf7a in FEngineLoop::Tick() ()
#17 0x098e874f in EngineTick() ()
#18 0x098e87cd in GuardedMain(wchar_t const*, void*, void*, int) ()
#19 0x098de8f7 in appMacCallGuardedMain() ()
#20 0x088f3a18 in main ()
(gdb) disassemble
Dump of assembler code for function _ZN9Scaleform6Render11ContextImpl7Context17clearRTHandleListEv:
   0x09aea010 <+0>:     push   %ebx
   0x09aea011 <+1>:     mov    0x8(%esp),%eax
   0x09aea015 <+5>:     mov    0x58(%eax),%edx
   0x09aea018 <+8>:     add    $0x4c,%eax
   0x09aea01b <+11>:    cmp    %eax,%edx
   0x09aea01d <+13>:    je     0x9aea050 <_ZN9Scaleform6Render11ContextImpl7Context17clearRTHandleListEv+64>
   0x09aea01f <+15>:    mov    0x8(%edx),%ebx
   0x09aea022 <+18>:    mov    0xc(%edx),%ecx
   0x09aea025 <+21>:    mov    0x18(%edx),%eax
   0x09aea028 <+24>:    mov    %ecx,0xc(%ebx)
   0x09aea02b <+27>:    mov    0xc(%edx),%ecx
   0x09aea02e <+30>:    test   %eax,%eax
   0x09aea030 <+32>:    mov    %ebx,0x8(%ecx)
   0x09aea033 <+35>:    je     0x9aea03c <_ZN9Scaleform6Render11ContextImpl7Context17clearRTHandleListEv+44>
   0x09aea035 <+37>:    andl   $0xfffffffe,0x8(%eax)
   0x09aea039 <+41>:    mov    0xc(%edx),%ecx
   0x09aea03c <+44>:    mov    0x8(%edx),%eax
   0x09aea03f <+47>:    mov    %ecx,0xc(%eax)
   0x09aea042 <+50>:    mov    0xc(%edx),%ecx
   0x09aea045 <+53>:    mov    %eax,0x8(%ecx)
=> 0x09aea048 <+56>:    jmp    0x9aea03c <_ZN9Scaleform6Render11ContextImpl7Context17clearRTHandleListEv+44>
   0x09aea04a <+58>:    lea    0x0(%esi),%esi
   0x09aea050 <+64>:    pop    %ebx
   0x09aea051 <+65>:    ret
End of assembler dump.

If my assembler knowwledge isn't that off, it an endless loop from 0x09aea048 to 0x09aea03c?

Yeah, it's Scaleform waiting for a "movies are done!" flag that never gets set for some reason, so it ends up in a loop. Not sure why on the 32-bit version does this, yet. Will know more soon.

--ryan.

Yeah it's looping and waiting for something to happen. I'm in there. But it doesn't check for an abort condition, i.e. there's no conditional jump. And unless I'm missing a pthread_cancel or similar, that will wait forever. Also the amd64 build does have a compare plus conditional jump

[..]
0000000001ed88d0 <+0x40> andq   $0xfffffffffffffffe,0x10(%rdx)
0000000001ed88d5 <+0x45> movq   $0x0,0x30(%rax)
0000000001ed88dd <+0x4d> mov    0xb0(%rdi),%rax
0000000001ed88e4 <+0x54> cmp    %rsi,%rax
0000000001ed88e7 <+0x57> jne    0000000001ed88a8 <+0x18>
0000000001ed88e9 <+0x59> repz retq
0000000001ed88eb <+0x5b> nop
0000000001ed88ec <+0x5c> nopl   0x0(%rax)

Also using gdb to single step up to 0x09aea048 and forcing the jump to 0x09aea050 let's it continue until the next indefinite hang.

Same exact problem.  Any resolution in sight?

I add my name to the problem of getting the game to start.  It hangs during the intro screen about saving.  I also noticed that the mouse disappears too, but it comes back after forcing the Sanctum 2 window closed.  I am runnuing Ubuntu 14.04 with Nvidia card and drivers.  I have played other Steam games without issues, this is the first one I have had a problem with.  I tried reloading and the suggestions in the forum but nothing works.  I see that this bug has been open for awhile, is there an ETA on  the fix?  If there is something you would like me to try, let me know.