[RESOLVED] Linux - Aborted (core dumped)

[__eMpTy__]

Testing out Alpha 10 on Steam.  The US2 window opens and the spinner spins for a moment, then it closes with no warning.  If I run it from the command line, I get a couple messages about Mono paths and config, and then "Aborted (core dumped)".  I've looked at the executable "Universe Simulator.x32" with ldd and I appear to have all the libraries installed.

I am using Kubuntu 14.04 on an AMD Phenom II x6 processor with a Nvidia 780ti graphics card running running the 340.24 drivers.

Any help would be great. I can provide more info, or the core dump file if needed.  Thanks!

[C7]

Hi there, that's exactly what I need!

If you could, put your log files, any dumps you've got, pretty much all your information.

Do you have OpenCL on your platform? (If so, what version) Also what is your Language set to?

[Caldazar]

I can confirm that error on
Arch Linux  (x86_64 GNU/Linux 3.16.1-1)
AMD Phenom II X4 960T - AMD Radeon HD 6670 with Catalyst

OpenCL seems ok > # clinfo
$LANG is de_DE.UTF-8

Code: [Select]

$ ldd ./"Universe Sandbox.x32"linux-gate.so.1 (0xf7709000)
libdl.so.2 => /usr/lib32/libdl.so.2 (0xf76d6000)
libpthread.so.0 => /usr/lib32/libpthread.so.0 (0xf76b9000)
librt.so.1 => /usr/lib32/librt.so.1 (0xf76b0000)
libGLU.so.1 => /usr/lib32/libGLU.so.1 (0xf762a000)
libGL.so.1 => /usr/lib32/libGL.so.1 (0xf758d000)
libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7456000)
libXext.so.6 => /usr/lib32/libXext.so.6 (0xf7441000)
libXcursor.so.1 => /usr/lib32/libXcursor.so.1 (0xf7436000)
libXrandr.so.2 => /usr/lib32/libXrandr.so.2 (0xf742b000)
libm.so.6 => /usr/lib32/libm.so.6 (0xf73de000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf73c3000)
libc.so.6 => /usr/lib32/libc.so.6 (0xf7201000)
/lib/ld-linux.so.2 (0xf770c000)
libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf710b000)
libatiuki.so.1 => /usr/lib32/libatiuki.so.1 (0xf70f0000)
libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf70ca000)
libXrender.so.1 => /usr/lib32/libXrender.so.1 (0xf70be000)
libXfixes.so.3 => /usr/lib32/libXfixes.so.3 (0xf70b8000)
libXau.so.6 => /usr/lib32/libXau.so.6 (0xf70b4000)
libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf70ad000)

Looks ok except  linux-gate.so and ld-linux.so which apparently aren't real libraries but "virtual shared objects exposed by the kernel at a fixed address in every process' memory"
/lib/ld-linux.so.2 might be problematic on a 64bit system as here its name should be /lib64/ld-linux-x86-64.so.2 and I can't just install a lib32 version of it.
But I don't know if that's related to our issue or problematic / relevant at all.

Anyways, $ coredumpctl gdb <pid>

Do you need the whole .xz file (21 MB) this output refers to?

EDIT: I forgot, the log file is needed of course.

[Caldazar]

Alright, I played around with gdb a bit and logged what happened.

Note that I don't know what I'm doing but the output looks usefull and I hope it is.

The commands I ran were
- info threads
- bt
- list
- run
- continue

If there's more I can do (and maybe laearn a thing or two about what's happening here) please say so, I'm having fun with this stuff .

[__eMpTy__]

Hi there, that's exactly what I need!

If you could, put your log files, any dumps you've got, pretty much all your information.

Do you have OpenCL on your platform? (If so, what version) Also what is your Language set to?

I have attached my ~/.config/unity3d/Giant Army/Universe Sandbox ²/Player.log
As far as OpenCL goes, I believe it is built into the proprietary drivers I am running.  I updated to them 340.32 but it didn't make any difference.

[C7]

Thanks for posting the logs. Sorry it took a while to respond. I've been busy with PAX and travelling up until today.

Your logs are citing the error as coming from the steam overlay. It's trying to load the wrong ELF Class for the library. I suspect that you're running a 64bit version of Universe Sandbox, and the overlay library for your steam is 32 bit.

Two things to try for now, one is to disable the steam overlay in the game.

You can  do this by selecting the game, going to properties -> General, and unchecking the option. Enable the steam overlay while in-game.

Unity should also deploy both 32bit and 64bit executables, you can navigate to the directory that the game is installed to and manually select and launch the 32 bit version instead.

[Caldazar]

I can't speak for __eMpTy__ but in my case that doesn't solve the issue.

I have deactivated the steam overlay anyways so that's not where the problem is.

Then I think I only have a  32 bit executable in the game folder, Universe Sandbox.x32, assuming the *.x32 means 32 bit.

Code: [Select]

$ cd '/home/michael/.local/share/Steam/SteamApps/common/Universe Sandbox 2' && find . -maxdepth 1 -type f -executable./libsteam_api.so
./steam_appid.txt
./libSteamworksNative.so
./Universe Sandbox.x32


I also tried to disable STEAM_RUNTIME as suggested in the Arch Wiki but that only lead me into dependency hell. After 1h and 50+ installed 32bit libraries I hit a dead end and gave up.
Even if that had gotten me around my issue it would be way too inconvenient to be called a 'solution'.

[ArcticTroll]

I'm getting the same problem, disabling steam overlay didn't work for me either.

Kubuntu 14.04
Intel Core i3-3240 CPU x4
GeForce GTX 660

[C7]

Thanks for all the patience, and info on testing this. After doing a lot of research we found out that the solution we use for our steamworks wrapper is the likely cause of the trouble. 

I'm going to investigate some possible replacements, and we'll see if we can get some new builds made for testing after that. But it might take some time to redo all our bindings to steamworks, if that's the solution we need to go with.

I'll keep everyone updated as we work towards fixes.

[Caldazar]

That's what I thought too: "Some steam stuff going wrong on a 64bit system" but I think I found a rather profane bug with openCL, as you assumed from the beginning. (again, I don't really know what's actually going on).

Workaround:

Place a softlink

Code: [Select]

ln -s /usr/lib/libOpenCL.so.1 '/home/<USERNAME>/.local/share/Steam/SteamApps/common/Universe Sandbox 2/Universe Sandbox_Data/Plugins/x86/liblibOpenCL.so.so'

After that the game starts.

Solution Process:

I traced what the Program was doing with strace

Code: [Select]

cd /home/michael/.local/share/Steam/SteamApps/common/Universe Sandbox 2/
strace -o ~/Downloads/strace_us2_2.txt ./"Universe Sandbox.x32"
the end of that log (attached) looked like this:
[...]
gettimeofday({1410389695, 561412}, NULL) = 0
gettimeofday({1410389695, 561555}, NULL) = 0
stat64("/home/michael/.local/share/Steam/SteamApps/common/Universe Sandbox 2/Universe Sandbox_Data/Plugins/x86", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/home/michael/.local/share/Steam/SteamApps/common/Universe Sandbox 2/Universe Sandbox_Data/Plugins/x86/liblibOpenCL.so.so", 0xffe8e080) = -1 ENOENT (No such file or directory)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x1} ---
sigreturn() (mask [])                   = 1
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x1} ---
sigreturn() (mask [])                   = 1
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x1} ---
sigreturn() (mask [])                   = 1
[...]

And so on, SIGSEGV galore.
Now
stat64("/home/michael/.local/share/Steam/SteamApps/common/Universe Sandbox 2/Universe Sandbox_Data/Plugins/x86/liblibOpenCL.so.so", 0xffe8e080) = -1 ENOENT (No such file or directory)

looks like a typo, and libOpenCL.so isn't there anyways, so I linked it and that worked.

Now I have no text inside the running application, but that's for another day 

[C7]

Well, that's not right at all... I'll take a look and see what the heck is happening there.

[ArcticTroll]

I noticed in the new update you had switched your Steamworks integration to fix startup issues for Linux users.  (And I assumed this was this problem), But it doesn't seem to be fixed :\ . It get's up to "Finding OpenCL devices" then crashes.

[C7]

There's two issues going on, we've hopefully fixed the seg faults due to steamworks issues. But that doesn't resolve the OpenCL failures.

If you're having it crash at OpenCL, we need your logs and any crash dump files so we can get it resolved.

In the meantime, you should be able to force cpu support by calling the program with the argument -forcecpu

[ArcticTroll]

Doing -forcecpu doesn't work for me. I have attached the Player.log, I don't know if/what other files you need.

[C7]

We found a couple of legacy issues in our build pipeline that are being fixed right now. We should have a new builds for Linux in the coming sub version of Alpha 11.

[ArcticTroll]

Game runs very nicely now, thank you for reacting and fixing it so quickly. Very nice game

[C7]

Ah, great. I'm glad to hear it's finally working for you. I'm sorry it's taken as long as it has.

Thank you everyone who's posted your logs and crash dumps, they've really helped to pin down exactly where the issues were.

Can any other Linux users confirm that this has resolved the issues for you?

[Caldazar]

Well, now I have a completely different error freezing the game but  the issue of this thread is solved afaics.

Regarding the new error, I'm looking into it right now and post a new thread as soon as I find something useful.

[C7]

Thanks Caldazar. I'll take a look a look at it once it's posted, and see if we can get it resolved.