[RESOLVED] libOpencl.so issue and crash when fixed (Nvidia's OpenCL)

[zithedragon]

9/4/14 : renamed to be more descriptive please look at 2nd post for clearer explanation of the problems

CPU: i5-3570k (overclocked to 4.3Ghz)
GPU: 2 GeForce GTX 670 2GB vram ( sli=auto )
RAM: 16GB DDR3 1600
OS: Lubuntu 14.04.1 x86_64


the GPU is not seen by UBox2 as a compute device ( just shows regular CPU ) even though OpenCL is installed and looks like its working since Luxmark is able to test the GPUs OpenCL performance have yet to try other OpenCL programs


edit 9/1/14 ::
tried different OpenCL drivers and ICD loader and still no luck right now using the Nvidia CUDA toolkit 6.5 version of the OpenCL drivers and loader(340.29).... the main problem seems to be that libOpenCL.so from with in the Universe Sandbox_Data folder is not loading

--- after looking a bit LibOpenCL.so is not located in "~/.local/share/Steam/SteamApps/common/Universe Sandbox 2/Universe Sandbox_Data/Mono/x86/" or in "~/.local/share/Steam/SteamApps/common/Universe Sandbox 2/Universe Sandbox_Data/Mono/x86/./"

edit 9/2/14 ::
found out that  LibOpenCL.so in /usr/lib/i386-linux-gnu and in /usr/lib/x86_64-linux-gnu had minor versions on the end and after setting up symlinks to fix the problem some opencl apps(like compiling clinfo) were having, but now Universe sanbox2 gets SIGSEGV. new log attached, no crash dumps found

edit 9/3/14 ::
changed some setting and now gdb add debug information to the log. added new log just in-case more information other than the new debug info is in it

[zithedragon]

The first bug is that Universe Sandbox 2 looks for libOpenCL.so and for at least the Nvidia implementation of the loader on Ubuntu(14.04) like distros do not create said file instead it creates libOpenCL.so.1 , libOpenCL.so.1.0 , and libOpenCL.so.1.0.0 , which makes Universe Sandbox2 not load OpenCL so it would be better if Universe Sandbox looked for one of them or at-least tell people that they need to do a symlink of one of those to create libOpenCL.so in the same folders that they are in


the second bug ends up being a crash after fixing the libOpenCL.so problem and the only way to fix it right now is to ether not have the icd files in /etc/OpenCL/vendors or to remove the libOpenCL.so symlink which means the compute device will be regular cpu

and I did manage to get a core dump to save
https://dl.dropboxusercontent.com/u/18395376/core

[C7]

Thank you for the detailed logs and information. You're having the same issue as what's happening in this thread. The steam overlay is actually causing the problem.

This is the relevant bit of the log file,

 gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32)

Can you try the debugging steps I posted in the linked thread below?

http://universesandbox.com/forum/index.php/topic,13304.0.html

Thanks

EDIT: Posting the relevant bit of the other post here.

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.

[zithedragon]

I have tried disabling the game overlay and no luck on getting rid of the  preload error and hiding the 32 bit version which end up giving the error that LD_PRELOAD cannot open shared object file ... also this error seems to be a common problem because steam comes with both versions and is usually harmless so im not sure how it can be whats causing the cloo .net/mono wrapper to act up in the libmono.so

the only executable is a .x32 (marked as executable) which im sure is a 32bit executable and when running it in the terminal I get the error:

zi@zi-linux-pc:~/.local/share/Steam/SteamApps/common/Universe Sandbox 2$ ls
libsteam_api.so  libSteamworksNative.so  steam_appid.txt  Universe Sandbox_Data  Universe Sandbox.x32
zi@zi-linux-pc:~/.local/share/Steam/SteamApps/common/Universe Sandbox 2$ ./"Universe Sandbox.x32"
./Universe Sandbox.x32: error while loading shared libraries: libGLU.so.1: wrong ELF class: ELFCLASS64

and I have both 32bit and 64bit versions of libGLU.so.1 (steam also comes with both) which is strange that when running through steam no error of that sort comes up

[C7]

Strange, I'm going to do some research and see if I can figure out why the ELF Classes keep mismatching like that.

[zithedragon]

well I think when you run steam to open the game it acts as a sort of wrapper which is why the libGLU.so.1 doesn't act up unless you open the game directly, but at the same time steam ends up messing up with preloading gameoverlayrenderer.so which doesn't seem to be a problem since even if i hide the opencl loader the error still occurs but there is no crash or stacktrace


the thing that should be looked at is the stacktrace of the last log file (9-3-14_debug-info_Player.log ) I added on the first post a while back and Im adding a text file which has just the stacktrace and gdb info which is whats causing the crash

[C7]

Thank you for the new information. I'll look into this as well.

It seems the issue is happening when we detect devices, and test which is best.

[jbrown11]

9/4/14 : renamed to be more descriptive please look at 2nd post for clearer explanation of the problems

CPU: i5-3570k (overclocked to 4.3Ghz)
GPU: 2 GeForce GTX 670 2GB vram ( sli=auto )
RAM: 16GB DDR3 1600
OS: Lubuntu 14.04.1 x86_64


the GPU is not seen by UBox2 as a compute device ( just shows regular CPU ) even though OpenCL is installed and looks like its working since Luxmark is able to test the GPUs OpenCL performance have yet to try other OpenCL programs


edit 9/1/14 ::
tried different OpenCL drivers and ICD loader and still no luck right now using the Nvidia CUDA toolkit 6.5 version of the OpenCL drivers and loader(340.29).... the main problem seems to be that libOpenCL.so from with in the Universe Sandbox_Data folder is not loading

--- after looking a bit LibOpenCL.so is not located in "~/.local/share/Steam/SteamApps/common/Universe Sandbox 2/Universe Sandbox_Data/Mono/x86/" or in "~/.local/share/Steam/SteamApps/common/Universe Sandbox 2/Universe Sandbox_Data/Mono/x86/./"

edit 9/2/14 ::
found out that  LibOpenCL.so in /usr/lib/i386-linux-gnu and in /usr/lib/x86_64-linux-gnu had minor versions on the end and after setting up symlinks to fix the problem some opencl apps(like compiling clinfo) were having, but now Universe sanbox2 gets SIGSEGV. new log attached, no crash dumps found

edit 9/3/14 ::
changed some setting and now gdb add debug information to the log. added new log just in-case more information other than the new debug info is in it

Have you tried:
1 - Force CPU Mode (turn off OpenCL)
- In Steam, Right-click on the game title under the 'Library' and select 'Properties'.
- Under the General tab click the 'Set launch options...' button.
- Enter  -forcecpu  into the launch options (note the dash) and click 'OK'.
- Close the game's 'Properties' window and launch the game.

2 - Set Graphics to Lowest Settings
- In Steam, Right-click on the game title under the 'Library' and select 'Properties'.
- Under the General tab click the 'Set launch options...' button.
- Enter  -safemode (or  -forcecpu -safemode  if you want both options on) into the launch options and click 'OK'.
- Close the game's 'Properties' window and launch the game.

[zithedragon]

@jbrown11

nether of those work

[C7]

As an update to this issue.

We've found a new implementation of steamworks that is a lot more friendly to the Linux platform, and is fully up to date.

We went through and redid all of our bindings to Steamworks and ripped out the old libraries that were causing issues. We're hoping to have some new builds here soon, so you can test to see if the issues are resolved.

[zithedragon]

still crashes while loading OpenCL through libmono.so, player log attached

edit::

core dump compressed into a 7zip with LZMA = https://www.dropbox.com/s/xcvd10n500aufod/core.7z?dl=0

[zithedragon]

since 11.1 has been released I have retested and the crash still occurs.. new player log attached and the core dump can be downloaded https://www.dropbox.com/s/xcvd10n500aufod/core.7z?dl=0 which is compressed with 7zip with LZMA

[C7]

Okay, I'll look into the build configuration next, now that we're using a functional Steamworks implementation.

Edit : Update

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.

[zithedragon]

well it seems to load but it still ends up crashing for some reason even though nothing seems to really show any problems

the only thing in the log that has any kind of interest to me is

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

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

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


after doing a system update I tried again and in the terminal I get

Found path: /home/zi/.local/share/Steam/SteamApps/common/Universe Sandbox 2/Universe Sandbox.x86_64
Mono path[0] = '/home/zi/.local/share/Steam/SteamApps/common/Universe Sandbox 2/Universe Sandbox_Data/Managed'
Mono path[1] = '/home/zi/.local/share/Steam/SteamApps/common/Universe Sandbox 2/Universe Sandbox_Data/Mono'
Mono config path = '/home/zi/.local/share/Steam/SteamApps/common/Universe Sandbox 2/Universe Sandbox_Data/Mono/etc'
CPU time limit exceeded (core dumped)
Game removed: AppID 230290 "Universe Sandbox ²", ProcID 3067

core dump compressed into a 7zip with LZMA = https://www.dropbox.com/s/vog5dbg9dlpqfbh/core.7z?dl=0
the log shows the same information

[zithedragon]

ok Universe sandbox2 is now working for me, it seems there where some conflicting libraries caused by the upgrading process

[C7]

Ah okay. Well, I'm glad to hear it's finally resolved. Those warnings you got in your logs are perfectly normal, and aren't harming anything.