[INFO][LINUX] Load screen freezes

[Caldazar]

Timeline:

After launching the game (through steam or directly with one of the x86 executives) a black window opens.

The game starts to log and does its kernel stuff which it exits with 0 after approx. 400ms ( both logs are attached).

After that the spinning loading symbol does its thing until the Player.log gets to

Platform assembly: /home/michael/.local/share/Steam/SteamApps/common/Universe Sandbox 2/Universe Sandbox_Data/Managed/System.Configuration.dll (this message is harmless)

and then it stops right there, freezing

The log then goes on with

UnloadTime: 1.899000 ms

and then in steps of ca. 500ms three times

Only one MaterialDatabase may exist in scene
 
(Filename: /BuildAgent/work/d63dfc6385190b60/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

and that's it, a frozen window.

At this point I have a process tree of

Code: [Select]

steam─┬─SteamChildMonit───Universe Sandbo─┬─25*[{Universe Sandbo}]
and four options to close the game window by signalling the "Universe Sandbo" (the direct child of SteamChildMonit)
HUP, INT, TERM or KILL

It then tells me that it's a Zombie and dies.

I tried

*The usual -forcecpu and -safemode
*Removing and redownloading the game
*export MONO_DISABLE_SHM=1 because there's no ~/.wapi folder (see Mono Specific Packaging help

all without avail

My System:
Arch Linux  (x86_64 GNU/Linux 3.16.3-1)
AMD Phenom II X4 960T - AMD Radeon HD 6670 with Catalyst

[C7]

Those messages are harmless by themselves. They're just a notification that the object is already created. Though, it really shouldn't be reloading the scene twice, or anything like that.

I'll do some testing here and double check the loading procedure.

You should have two executable files though, the .x86 and the x86_64. Have you tried them both, and if so, is the behavior at all different, or do the log files have any discrepancies? (You should be running x86_64, or it will have issues.)

I notice that Steam is showing it's installing a package during load. Can you verify steam has all its dependencies, as well as Universe Sandbox? I'd appreciate the output of ldd on your system, so I can take a look at the environment.

Also, we are loading a database, and I've seen issues with the system language causing parsing to fall apart. Due to it confusing , and .

Can you make sure you're launching with the option below?

LC_ALL=C

may also need this LD_LIBRARY_PATH="/usr/lib:$LD_LIBRARY_PATH"

[Caldazar]

I've attached all the logs and diff files as a zip package trying to give the files meaningful names. Tell me if they aren't self-explanatory.

Alright, the most interesting outcome first:

1. LC_ALL=C

Code: [Select]

LC_ALL=C ./"Universe Sandbox.x86_64"solves another error, the missing text I mentioned. Now I have the loading screen telling me what it does and it freezes at
"Starting the sandbox"

2.  .x86 vs. x86_64
The GUI behaves exactly the same, the Player-log is slightly different however. x86 stops at UnloadTime: 1.853000 ms
and doesn't do the database stuff.

3. LD_LIBRARY_PATH
It's now /usr/lib:
This seems to solve the ld.so error and also leaves out the database warnings.

4. ldd
I forgot to mention that in my last post

Code: [Select]

ldd ./"Universe Sandbox.x86_64"
        linux-vdso.so.1 (0x00007fffb29fc000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fa92ae7c000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fa92ac60000)
        librt.so.1 => /usr/lib/librt.so.1 (0x00007fa92aa58000)
        libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00007fa92a7d7000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0x00007fa92a5f5000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fa92a2b3000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x00007fa92a0a1000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00007fa929e96000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007fa929c8c000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007fa929987000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fa929771000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fa9293ce000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa92b080000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa9290bf000)
        libatiuki.so.1 => /usr/lib/libatiuki.so.1 (0x00007fa92b14d000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fa928e9d000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007fa928c93000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007fa928a8d000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fa928889000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fa928683000)
No problems as far as I can say.

I don't know how to check steam itself however:

Code: [Select]

LC_ALL=C ldd `which steam`not a dynamic executable
EDIT:
but

Code: [Select]

cd ~/.local/share/Steam/ubuntu12_32
LD_LIBRARY_PATH=".:${LD_LIBRARY_PATH}" ldd $(file *|sed '/ELF/!d;s/:.*//g')|grep 'not found'|sort|uniqhas a lot of "not found" which should be covered by the steam runtime. But I'll check that.
EDIT2: Yep, they are all there.

[C7]

Checking your logs, you're still getting mismatched ELF classes on the executable. It's using the 32 bit .so files for the overlay renderer instead of the 64bit ones.

This should of been fixed in the 11.2 update. I have seen it reported that it was necessary to completely uninstall and re-install the game after the 11.2 update to have the fix work. Since there's leftover incorrect files that are no longer part of the repository, but get used anyways. (Steam's not tracking them anymore)

This is an excerpt from the player_x86_64_LD_LIBRARY_PATH.log file.

ERROR: ld.so: object '/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32)

It should be using this library instead

Steam/ubuntu12_64/gameoverlayrenderer.so

[Caldazar]

After a bit of research and experimenting, I can say that the ld.so cannot be preloaded message is harmless as Valve's issue list claims.
It just tries to load the 32bit version, if unsucessfully, loads the 64bit version.

I think we can ignore that particular error.

My little experiments:

1. Link the 32bit to the 64bit version.
Error message is gone, some differences in the GLX settiings but apart from that, no effect.

2. Remove the 64bit version
ERROR: ld.so: object '/home/michael/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/michael/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

Apart from the log no effect on the game loading process.

[C7]

It's really strange, it appears that the application has started normally, then it just shuts down with no message in the logs. I've added better logging to the application's shutdown paths here, so I can hopefully figure out what's going on in the next revision.

I've been researching the current Steam Issues for Arch Linux as well, and it appears that there's an open issue if you have "remember my password" checked.

You should be able to uncheck it and run steam with steam --reset to clear out the bad caches.

It's a bit of a shot in the dark, but worth a try.

EDIT: How long are you waiting for the application to start up? I'm wondering if it's just taking a really long time. Do you mind letting it run for a bit, and seeing if it eventually crashes, instead of just becoming unresponsive?

[Caldazar]

A little update of where I am in my "research" (aka googling and messing with stuff I have no idea of).

The game hangs now for 3 hrs, sleeping.
The hanging process has the pid 1599, 'bash' is its grand-grand-parent

Code: [Select]

ps -lF S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
0 S  1000   752   632  0  80   0 -  4513 wait   pts/1    00:00:00 bash

so bash is waiting for a child

Code: [Select]

strace -p 1599futex(0x7fb7b523d0d0, FUTEX_WAIT_PRIVATE, 0, NULL

so the process is hanging in a futex_wait, sleeping forever (NULL) or until it gets a futex_wake (see =>)

Code: [Select]

sudo gdb -p 1599[...]
Got object file from memory but can't read symbols: File truncated.
0x00007fb7b8cfc910 in sem_wait () from /usr/lib/libpthread.so.0

Those are the last lines, full log is attached.

What all this means, I have no idea. Looks like its waiting for some sort of feedback that never comes.

I haven't reset Steam yet but it's one of the next things I'll try.

[Caldazar]

The steam reset didn't do anything useful but on my attempts to narrow down on the problem three names cross my way all the time:
- mono
- glibc
- to a lesser extend, pulseaudio

1. rt_sigsuspend(~[INT QUIT ABRT TERM XCPU RTMIN RT_1], 8
For some reason which I don't remember that line caught my eye and I googled it.
Especially the bug with qemu-arm-static sounded a lot like what I was seeing.

2. Not a freeze but an infinite loop
Universe Sandbox process (pid=13780) opens a couple of threads. Most of them do nothing but sleep and wait.
But there are three threads using the cpu, caught in something that looks like an infinite loop, approx. 100 times / sec..

13793:
Polling something again and again. The pid 655 in the log (just one loop) is pulseaudio.

13794:
FUTEX_LOCK and FUTEX_UNLOCK endlessly with some counter running.

13795:
does just
    nanosleep({0, 10000000}, NULL)          = 0
over and over again

When I signal SIGQUIT to 13793, it gets me a coredump of the whole affair and a quite interesting new Player.log (attached)

Code: [Select]

coredumpctl gdb 13780 is attached

After running US² through gdb, I have again a new Player.log (attached)

Summary:
Besides glibc and pulseaudio it's mostly mono, all over the place.
I tried to run US² through my native mono version instead of your bundled libmono.so but that didn't make any sense at all. It just complained about a ton of missing functions.

So is there any way that when building the sandbox, mono somehow gets into the way, maybe because it's not getting to grips with pulseaudio? Something like that.
Or do I totally misinterpret those logs?

[C7]

In regards to Mono, we're locked into the custom version that Unity is dependent on. When we build from Unity it handles everything to do with those libraries. If there's a bug in Mono, it's an engine bug, and we can't do much about it. But, if that's the case I can at least reproduce it and file a bug with Unity. If you're attempting any custom modifications of the settings for mono, it might actually be best to revert to standard for the purposes of testing this issue.

I've been searching all morning and I'm not seeing much information for running Unity games on ArchLinux, or potential fixes. I wonder if there's any other Linux users on the forums, with a working installation that we can compare library versions with. It does seem specific to your Linux Distro.

I did find some issues with AMD catalyst drivers and Unity3d games, along with some information that there games will lock up if you have two gpus registered in xorg.conf. What version of the Catalyst drivers are you running?

Checking on the ArchLinux Wiki for other Unity games, it appears that this is the recommended launch settings.

LD_LIBRARY_PATH="/usr/lib:$LD_LIBRARY_PATH" LC_ALL=C %command%_64

If it's dying on a thread, I can see about some command line options to disable the threading and async loading for debugging purposes. At least that way we can rule out our own internal thread handling, and see if the issue is actually coming from one of Unity's spawned internal threads.

[Caldazar]

I'm running Catalyst 14.4 with Xorg 1.15.2.

xorg.conf

Code: [Select]

Section "ServerLayout"
Identifier     "aticonfig Layout"
Screen      0  "aticonfig-Screen[0]-0" 0 0
EndSection

Section "Module"
EndSection

Section "Monitor"
Identifier   "aticonfig-Monitor[0]-0"
Option     "VendorName" "ATI Proprietary Driver"
Option     "ModelName" "Generic Autodetecting Monitor"
Option     "DPMS" "true"
EndSection

Section "Device"
Identifier  "aticonfig-Device[0]-0"
Driver      "fglrx"
BusID       "PCI:1:0:0"
EndSection

Section "Screen"
Identifier "aticonfig-Screen[0]-0"
Device     "aticonfig-Device[0]-0"
Monitor    "aticonfig-Monitor[0]-0"
DefaultDepth     24
SubSection "Display"
Viewport   0 0
Depth     24
EndSubSection
EndSection
Then:

Code: [Select]

LD_LIBRARY_PATH="/usr/lib:$LD_LIBRARY_PATH" LC_ALL=C ./"Universe Sandbox.x86_64
makes no difference at all.

I have 4 Unity3d games, two of them work alright, one gets a segmentation fault like this

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

and then your game, hanging without such an obvious hint.

There also is no obvious difference in the logs of the working games. The US2 log just stops at a point where they keep on going.

I'll try to get the game running on my laptop running SolydK and then compare the outcome. Maybe we get something useful from that.

[C7]

In your working games, can you check their log files and compare the version of the Unity Engine they're using? I'm wondering if perhaps this bug is dependent on the engine version itself. It should be at the top of the log file.

[Caldazar]

Hard to tell, the non-Steam game uses the same version as you do but the Steam game a little older one.

In Exilum (Non Steam)  4.5.3f3
ReignMaker(Steam) 4.5.2f1

[Caldazar]

Alrighty then, got it!
Working player.log attached

1. US2 works fine on my SolydK laptop. A bit stuttery but it runs fine for an alpha.

2. One difference in the Player.log there is that it doesn't do
[...]
requesting resize 1280 x 720
resizing window to 1280 x 720
Desktop is 1920 x 1080 @ 60 Hz
Platform assembly: /home/michael/.local/share/Steam/SteamApps/common/Universe Sandbox 2/Universe Sandbox_Data/Managed/System.Configuration.dll (this message is harmless)
UnloadTime: 1.909000 ms
[...]

3. Deleting that file on Arch makes US2 run there too. Loading is a really bumpy ride with lots of scratching harddisk I/O but it ultimately starts after ca 10 seconds.

Another effect is that the window now fills up the available desktop space instead of just being 1280 x 720 wide.

Restoring the file  restores the smaller window and the freeze.

So there's something in
~/.local/share/Steam/SteamApps/common/Universe Sandbox 2/Universe Sandbox_Data/Managed/System.Configuration.dll

my Arch system doesn't like.
And why is it part of 'Platform Assembly' here but not on SolydK in the first place? Something with my monitor?

Additional note: Disabling PulseAudio and running bare Alsa instead didn't change anything. Just in case that info is useful.

EDIT:
http://universesandbox.com/forum/index.php/topic,13499.0.html looks similar

[C7]

Well, that's pretty bizzare. I'll look into that .dll file and see what I can find out what is up with it.

I'm really glad it's finally working for you!

Now, I've got to see about what portions of this we can automate to make it easier for users to install the game.