OpenXcom Forum
OpenXcom => Troubleshooting => Topic started by: livewirerc on November 03, 2018, 12:54:53 am
-
I'm not sure if this is a user error (my assumption) or a bug, but here we go. Ever since updating to Fedora 29 I'm plagued with this error whenever I attempt to run the Nightly build. I've tried re-installing all dependency packages, but no dice. Anybody know what's up with this:
[02-11-2018_17-47-04] [INFO] Data folder is: /home/jabels/.local/share/openxcom/
[02-11-2018_17-47-04] [INFO] Data search is:
[02-11-2018_17-47-04] [INFO] - /home/jabels/.local/share/openxcom/
[02-11-2018_17-47-04] [INFO] - /tmp/.mount_X_Openycitek/usr/share//openxcom/
[02-11-2018_17-47-04] [INFO] - /home/jabels/.local/share/flatpak/exports/share//openxcom/
[02-11-2018_17-47-04] [INFO] - /var/lib/flatpak/exports/share//openxcom/
[02-11-2018_17-47-04] [INFO] - /usr/local/share//openxcom/
[02-11-2018_17-47-04] [INFO] - /usr/share//openxcom/
[02-11-2018_17-47-04] [INFO] - /usr/local/share/openxcom/
[02-11-2018_17-47-04] [INFO] - /usr/share/openxcom/
[02-11-2018_17-47-04] [INFO] - /usr/share/openxcom//
[02-11-2018_17-47-04] [INFO] - ./
[02-11-2018_17-47-04] [INFO] User folder is: /home/jabels/.local/share/openxcom/
[02-11-2018_17-47-04] [INFO] Config folder is: /home/jabels/.config/openxcom/
[02-11-2018_17-47-04] [INFO] Options loaded successfully.
[02-11-2018_17-47-04] [INFO] SDL initialized successfully.
[02-11-2018_17-47-04] [INFO] SDL_mixer initialized successfully.
[02-11-2018_17-47-04] [INFO] requested file not found: openxcom.png
[02-11-2018_17-47-04] [INFO] Attempting to set display to 1920x1080x32...
[02-11-2018_17-47-04] [ERROR] Couldn't find matching GLX visual
[02-11-2018_17-47-04] [INFO] Attempting to set display to default resolution...
[02-11-2018_17-47-04] [FATAL] A fatal error has occurred: Couldn't find matching GLX visual
[02-11-2018_17-47-04] [FATAL] /tmp/.mount_X_Openycitek/usr/bin/openxcom(_ZN8OpenXcom13CrossPlatform10stackTraceEPv+0x2a) [0x605e8a]
[02-11-2018_17-47-04] [FATAL] /tmp/.mount_X_Openycitek/usr/bin/openxcom(_ZN8OpenXcom13CrossPlatform9crashDumpEPvRKSs+0x427) [0x6066a7]
[02-11-2018_17-47-04] [FATAL] /tmp/.mount_X_Openycitek/usr/bin/openxcom(_Z15exceptionLoggerv+0x5e) [0x4c67ce]
[02-11-2018_17-47-04] [FATAL] /lib64/libstdc++.so.6(+0x972fc) [0x7fb3104562fc]
[02-11-2018_17-47-04] [FATAL] /lib64/libstdc++.so.6(+0x97357) [0x7fb310456357]
[02-11-2018_17-47-04] [FATAL] /lib64/libstdc++.so.6(+0x975b8) [0x7fb3104565b8]
[02-11-2018_17-47-04] [FATAL] /tmp/.mount_X_Openycitek/usr/bin/openxcom(_ZN8OpenXcom6Screen12resetDisplayEb+0xc83) [0x6cba93]
[02-11-2018_17-47-04] [FATAL] /tmp/.mount_X_Openycitek/usr/bin/openxcom(_ZN8OpenXcom6ScreenC2Ev+0x72) [0x6cbee2]
[02-11-2018_17-47-04] [FATAL] /tmp/.mount_X_Openycitek/usr/bin/openxcom(_ZN8OpenXcom4GameC2ERKSs+0x12a) [0x62111a]
[02-11-2018_17-47-04] [FATAL] /tmp/.mount_X_Openycitek/usr/bin/openxcom(main+0xd6) [0x4ae906]
[02-11-2018_17-47-04] [FATAL] /lib64/libc.so.6(__libc_start_main+0xf3) [0x7fb31007e413]
[02-11-2018_17-47-04] [FATAL] /tmp/.mount_X_Openycitek/usr/bin/openxcom() [0x4b088a]
[02-11-2018_17-47-04] [FATAL] OpenXcom has crashed: Couldn't find matching GLX visual
More details here: /home/jabels/.local/share/openxcom/openxcom.log
If this error was unexpected, please report it to the developers.
Any assistance is greatly appreciated.
Jason
-
Could you please indicate where you got the nightly build from?
That might us help tracing down the error
-
Could you please indicate where you got the nightly build from?
That might us help tracing down the error
Sure thing! I used the latest (at the time) nightly build for Linux from https://openxcom.org/git-builds/. Here are the details of that build:
2018-11-02 46604b559 64-bit 32-bit
I also tried the following builds from 10/8 and 10/14, which worked prior to the Fedora 29 upgrade:
2018-10-14 7d9cd996e 64-bit 32-bit
2018-10-08 13049d617 64-bit 32-bit
I'm seeing the same error each time.
-
Ok thank you for that information.
Currently i am suspecting something is wrong in relation to the openGL libraries.
If you can find the openxcom binary could you post back to us the results of
ldd openxcom
Also can you indicate if you are using fedora's default display driver or if you have installed some other driver?
Thank you
-
It looks like your graphics drivers are broken. What graphics card do you have? Have you installed any non-free drivers (e.g. the AMD/NVidia binary drivers if it's one of those cards)?
Can you try running the "glxinfo" command in a terminal and pasting the output? It should be in the "glx-utils" package if not already installed.
-
It looks like your graphics drivers are broken. What graphics card do you have? Have you installed any non-free drivers (e.g. the AMD/NVidia binary drivers if it's one of those cards)?
Can you try running the "glxinfo" command in a terminal and pasting the output? It should be in the "glx-utils" package if not already installed.
I'm on a Lenovo Thinkpad x260, so it's the Intel HD 520 integrated graphics. and I believe I'm using whatever comes with Fedora. I initially installed 28, but just upgraded to 29 which is when things broke. Other games seem to run just fine, it's only affecting OpenXCom. I've been running Steam games, Battle for Wesnoth, can launch glxgears, so all that seems ok.
I've attached the glxinfo output as a file since cut and pasting it is making it look real ugly. Thanks for taking a look!
-
Weird - this error is from SDL, not openxcom directly. Maybe the update broke that? Assuming you've checked you've got the latest version of sdl1.x installed as well (OpenXcom is oldschool so still uses sdl1.x, not 2 FYI)
I can't see anything in the openxcom code that would cause this - we don't ask for any weird attributes that can't be satisfied by any of the glx visuals listed in the glxinfo output....
It might be interesting to try to get an apitrace of openxcom failing to start - it should hopefully list the glx calls that sdl is trying to do, and which is failing. It may give us pointers on what's going on?
-
Weird - this error is from SDL, not openxcom directly. Maybe the update broke that? Assuming you've checked you've got the latest version of sdl1.x installed as well (OpenXcom is oldschool so still uses sdl1.x, not 2 FYI)
I can't see anything in the openxcom code that would cause this - we don't ask for any weird attributes that can't be satisfied by any of the glx visuals listed in the glxinfo output....
It might be interesting to try to get an apitrace of openxcom failing to start - it should hopefully list the glx calls that sdl is trying to do, and which is failing. It may give us pointers on what's going on?
Thanks again for looking. So I took the nuclear option and re-installed all of the SDL-related packages by running 'sudo dnf reinstall SDL* -y', and here's what it re-installed:
Reinstalled:
SDL-1.2.15-33.fc29.x86_64 SDL-devel-1.2.15-33.fc29.x86_64
SDL-static-1.2.15-33.fc29.x86_64 SDL2-2.0.8-6.fc29.i686
SDL2-2.0.8-6.fc29.x86_64 SDL2-devel-2.0.8-6.fc29.x86_64
SDL2-static-2.0.8-6.fc29.x86_64 SDL2_gfx-1.0.3-3.fc29.x86_64
SDL2_gfx-devel-1.0.3-3.fc29.x86_64 SDL2_gfx-docs-1.0.3-3.fc29.noarch
SDL2_image-2.0.3-2.fc29.x86_64 SDL2_image-devel-2.0.3-2.fc29.x86_64
SDL2_mixer-2.0.2-5.fc29.x86_64 SDL2_mixer-devel-2.0.2-5.fc29.x86_64
SDL2_net-2.0.1-7.fc29.x86_64 SDL2_net-devel-2.0.1-7.fc29.x86_64
SDL2_ttf-2.0.14-7.fc29.x86_64 SDL2_ttf-devel-2.0.14-7.fc29.x86_64
SDL_Pango-0.1.2-27.fc29.x86_64 SDL_Pango-devel-0.1.2-27.fc29.x86_64
SDL_gfx-2.0.25-9.fc29.x86_64 SDL_gfx-devel-2.0.25-9.fc29.x86_64
SDL_image-1.2.12-20.fc29.x86_64 SDL_image-devel-1.2.12-20.fc29.x86_64
SDL_mixer-1.2.12-16.fc29.x86_64 SDL_mixer-devel-1.2.12-16.fc29.x86_64
SDL_mng-0.2.7-8.fc29.x86_64 SDL_mng-devel-0.2.7-8.fc29.x86_64
SDL_net-1.2.8-13.fc29.x86_64 SDL_net-devel-1.2.8-13.fc29.x86_64
SDL_sound-1.0.3-22.fc29.x86_64 SDL_sound-devel-1.0.3-22.fc29.x86_64
SDL_ttf-2.0.11-13.fc29.x86_64 SDL_ttf-devel-2.0.11-13.fc29.x86_64
Unfortunately, OpenXcom is still failing for me:
$ ./OpenXcom_20181103_d3affd504_x86-64.AppImage
zenity: /tmp/.mount_OpenXczJPfcu/lib/x86_64-linux-gnu/libdbus-1.so.3: no version information available (required by /lib64/libatk-bridge-2.0.so.0)
zenity: /tmp/.mount_OpenXczJPfcu/lib/x86_64-linux-gnu/libdbus-1.so.3: no version information available (required by /lib64/libatspi.so.0)
(zenity:2105): Gtk-WARNING **: 08:22:52.681: Could not find the icon 'dialog-error-ltr'. The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
http://icon-theme.freedesktop.org/releases
(zenity:2105): Gtk-WARNING **: 08:22:52.681: Could not load a pixbuf from /org/gtk/libgtk/icons/48x48/status/image-missing.png.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/48x48/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
OpenXcom has crashed: Couldn't find matching GLX visual
More details here: /home/jabels/.local/share/openxcom/openxcom.log
If this error was unexpected, please report it to the developers.
Aborted (core dumped)
I've not used apitrace before, but I'll snag it and see if I can figure it out.
--- posts merged. Come on people, it's not like I have nothing better to do! ---
So... I fixed it.
Not sure WHAT was causing the problem, but after tiring of bashing my head against packages, dependencies and permissions, I re-created my directories under a new user account, copied over my game data, saves, config file and ran it... and it crashed again. So I deleted the ./config/openxcom/options.cfg file, and it launched! Only at default resolution, but that's easy enough to change. Now to figure out WHAT it was in my original config file that caused me a few days of heartache.
Attached is the busted options file that was causing the issue, and also the cleanly-made, working one from launching the game fresh.
Thanks for all y'alls tips and assistance. Glad in the end it was something simple.
-
I'm guessing "useOpenGL: false" vs "useOpenGL: true" is the relevant difference.
-
Yup, that's what I found as well.
If I choose any setting that enables OpenGL, it crashes as soon as I apply the setting, and then continues to crash when I try to re-load the app. 5xrounded, Scale2x, Scale4x, etc. all fail.
Here are the lines that work from my config file:
useOpenGL: false
useOpenGLShader: Shaders/Raw.OpenGL.shader
And here's what doesn't (from my original config):
useOpenGL: true
useOpenGLShader: Shaders/scale4xhq.opengl.shader
Now I'm wondering what broke OpenGL. Damn this is frustrating, but at least the game launches now.
Edit: So OpenGL works just fine in other games. Fired up Extreme Tuxracer and everything looked and acted right. Now I'm left wondering why only OpenXcom seems to be affected?
2nd Edit: So far this seems entirely isolated to OpenXcom. All other OpenGL-reliant games I've tried are good. I can run 0ad, Extreme Tux, Foobillard, anything in my Steam library, no issues.
-
I'm guessing openxcom somehow cannot find the required library.
Please try the following command:
ldd $(which openxcom) | grep GL
This command will display the shared objects openxcom depends on, and tells you where they are located. The grep part filters to those lines containing GL in their name.
Just so we can be sure it looks at the right place.
-
I'm guessing openxcom somehow cannot find the required library.
No, it finds all libraries just fine or there wouldn't be any log and it wouldn't run with GL disabled.
-
Do I just run it like this?
$ ldd ./OpenXcom_20181104_92150fc6b_x86-64.AppImage
not a dynamic executable
Because I'm not getting any output aside from "not a dynamic executable" if so.
I do when I run it against apps in the /bin directory:
$ ldd /bin/foobillard | grep GL
libGL.so.1 => /lib64/libGL.so.1 (0x00007ff56deec000)
libGLU.so.1 => /lib64/libGLU.so.1 (0x00007ff56de78000)
libGLX.so.0 => /lib64/libGLX.so.0 (0x00007ff56da0c000)
libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007ff56d7f3000)
I'm just downloading the nightly .AppImage file and setting execute permissions on it. Should I be doing something else?
-
Appimages unfortunately for this case are a bit more than a simple binary (which contributes to one of their strengths).
What you can do is extract it and check the binary inside (probably best to use a throwaway folder so the rest of the system stays clear), something akin:
mkdir ./temporal-name
# Copy the .AppImage there
cd ./temporal-name
./OpenXcom_20181104_92150fc6b_x86-64.AppImage --appimage-extract
This should create a folder inside that dir containing the content of the appimage, the openxcom binary should be locate somewhere beneath the folder
-
Appimages unfortunately for this case are a bit more than a simple binary (which contributes to one of their strengths).
What you can do is extract it and check the binary inside (probably best to use a throwaway folder so the rest of the system stays clear), something akin:
mkdir ./temporal-name
# Copy the .AppImage there
cd ./temporal-name
./OpenXcom_20181104_92150fc6b_x86-64.AppImage --appimage-extract
This should create a folder inside that dir containing the content of the appimage, the openxcom binary should be locate somewhere beneath the folder
Thank you! I will give this a shot when I return home and will report back with the results.