# Description of problem: After upgrading Fedora 33→34 on Macbook 2013, game "Divinity Original Sin Enhanced Edition" always crashes on start with stacktrace: (0) /usr/lib/libpthread.so.0 : +0x13870 [0x7fd082419870] (1) ./libOGLBinding.so : api::OpenGLRenderer::ApplyConstants()+0x65 [0x7fd082d91845] (2) ./libRenderFramework.so : rf::Renderer::Apply(bool)+0x57 [0x7fd082a35437] (3) ./EoCApp : bik::BinkManager::Render()+0x260 [0xe91920] (4) ./EoCApp : ig::IggyBinding::IggyCustomDrawCallback(Iggy*, IggyCustomDrawCallbackRegion*)+0x382 [0xecf302] (5) ./EoCApp() [0x1235500] (6) ./EoCApp() [0x1237156] (7) ./EoCApp() [0x12357e9] (8) ./EoCApp() [0x1237156] (9) ./EoCApp() [0x12377f5] (10) ./EoCApp : IggyPlayerDrawTile+0x52 [0x1245382] (11) ./EoCApp : ig::FlashPlayer::Render(ls::ObjectHandle const&, ls::ObjectHandle const&)+0x1ad [0xed432d] (12) ./EoCApp : ig::IggyBinding::Render(rf::Renderer*, ls::IFlashPlayer*)+0xae [0xed045e] (13) ./libGameEngine.so : BaseApp::BeginDrawGUI(rf::Renderer*)+0xb0 [0x7fd082b91ea0] (14) ./libGameEngine.so : BaseApp::MakeFrame()+0x326 [0x7fd082b92456] (15) ./libGameEngine.so : BaseApp::OnIdle()+0xe0 [0x7fd082b90cb0] (16) ./EoCApp : main+0x170 [0x6d5180] (17) /usr/lib/libc.so.6 : __libc_start_main+0xd5 [0x7fd082261b25] (18) ./EoCApp : _start+0x29 [0x6d4ef9] I have done a lot of research, and here's what I found: * it is reproducible with i965 and with `LIBGL_ALWAYS_SOFTWARE=1`, but not with iris nor radeonsi. * trying to bisect Fedora packages yielded: * last known working version 1.20.11 (latest available package on F33) * first known broken version 21.1.1 (earliest available package on F34) * it is reproducible on Gnome and Sway I tried building XWayland myself to bisect it further, but I can't seem to get it to work with Gnome (and with Sway older XWayland refuses to run the game with infinite loop of some odd errors about messagebox). I suppose Fedora might have carried some mandatory patches, so just trying to bisect upstream won't work here. At this point I figured it might be more effective to report the bug, so here it is. # Version-Release number of selected component (if applicable): 21.1.2-1 # Steps to Reproduce (in terms of terminal commands): $ cd ~/.steam/steam/steamapps/common/Divinity\ Original\ Sin\ Enhanced\ Edition/ $ LIBGL_ALWAYS_SOFTWARE=1 ./runner.sh ## Actual results: Black window appears, and a second later a messagebox with crash information pops up. ## Expected results: Game window appears, and then main menu gets loaded.
It's a client crash, unlikely to be Xwayland though. Does the same work in Xorg?
(In reply to Olivier Fourdan from comment #1) > It's a client crash, unlikely to be Xwayland though. Well, downgrading Xwayland fixes the problem. I now keep a backup of the older Xwayland binary just for the case we want to play Divinity. > Does the same work in Xorg? No crashes in Xorg, the problem is Wayland-specific.
For the record, I found this report on Steam for a very similar crash… from 2015: https://steamcommunity.com/app/373420/discussions/0/451848854987459089/?ctp=3 For the very same game.
(In reply to Olivier Fourdan from comment #3) > For the record, I found this report on Steam for a very similar crash… from > 2015: > > https://steamcommunity.com/app/373420/discussions/0/451848854987459089/?ctp=3 > > For the very same game. This is another bug, it was reported and fixed in Mesa back then https://gitlab.freedesktop.org/mesa/mesa/-/issues/999 See how the last frame of the crash if `ChangeShader`. In the current report the last frame is `ApplyConstants`
(In reply to Konstantin from comment #4) > (In reply to Olivier Fourdan from comment #3) > > For the record, I found this report on Steam for a very similar crash… from > > 2015: > > > > https://steamcommunity.com/app/373420/discussions/0/451848854987459089/?ctp=3 > > > > For the very same game. > > This is another bug, it was reported and fixed in Mesa back then > https://gitlab.freedesktop.org/mesa/mesa/-/issues/999 See how the last frame > of the crash if `ChangeShader`. In the current report the last frame is > `ApplyConstants` Although, the Mesa commit is dated by 2019, hm. Then it's good I guess me with my gf started playing this game in 2020 after all of that was sorted out ☺
One possibility is that Xwayland 21.1 exposes more configs or visuals than Xwayland 1.20.x and that might trigger a bug in the game (that is just a theory, you could compare the output of glxinfo between 1.20 and 21.1 to see what I mean), but FWIW, I am not convinced this really is a bug in Xwayland yet, that sounds more like either Mesa or the game itself. Meanwhile I am installing that game on a laptop with NVIDIA to see how that goes.
Oh… I have a question, comment 0 says works with hardware acceleration (iris or radeonsi) but fails with the software renderer, why do you want to use LIBGL_ALWAYS_SOFTWARE=1?
(In reply to Olivier Fourdan from comment #7) > Oh… I have a question, comment 0 says works with hardware acceleration (iris > or radeonsi) but fails with the software renderer, why do you want to use > LIBGL_ALWAYS_SOFTWARE=1? It fails with i965 driver :-) The `LIBGL_ALWAYS_SOFTWARE=1` in steps to reproduce is only used because it makes it easy to reproduce the problem in absence of a i965-managed hardware.
But the same works with the iris driver?
(In reply to Olivier Fourdan from comment #9) > But the same works with the iris driver? Yep. The problem is on my gf's notebook with i965 driver. And I have another laptop, with iris and radeonsi drivers, and there I can only reproduce the crash with `LIBGL_ALWAYS_SOFTWARE=1`. > One possibility is that Xwayland 21.1 exposes more configs or visuals than Xwayland 1.20.x and that might trigger a bug in the game (that is just a theory, you could compare the output of glxinfo between 1.20 and 21.1 to see what I mean) Thanks for the hint! I'll compare the output once I'll be able to access the laptop with i965 (in 2 days).
(In reply to Olivier Fourdan from comment #6) > Meanwhile I am installing that game on a laptop with NVIDIA to see how that > goes. Thank you very much by the way for looking into this!
As you mentioned, this is affecting only i965 and the SW renderer, it works with NVIDIA closed source driver, iris, and others. To reproduce with i965, simple use: $ cd ~/.steam/steam/steamapps/common/Divinity\ Original\ Sin\ Enhanced\ Edition/ $ MESA_LOADER_DRIVER_OVERRIDE=i965 ./runner.sh
(In reply to Olivier Fourdan from comment #12) > As you mentioned, this is affecting only i965 and the SW renderer, it works > with NVIDIA closed source driver, iris, and others. > > To reproduce with i965, simple use: "*without i965" :) With i965 it's enough to just run the game, no env. variables needs to be set. > $ cd ~/.steam/steam/steamapps/common/Divinity\ Original\ Sin\ Enhanced\ > Edition/ > $ MESA_LOADER_DRIVER_OVERRIDE=i965 ./runner.sh
(In reply to Konstantin from comment #13) > (In reply to Olivier Fourdan from comment #12) > > As you mentioned, this is affecting only i965 and the SW renderer, it works > > with NVIDIA closed source driver, iris, and others. > > > > To reproduce with i965, simple use: > > "*without i965" :) With i965 it's enough to just run the game, no env. > variables needs to be set. > > > $ cd ~/.steam/steam/steamapps/common/Divinity\ Original\ Sin\ Enhanced\ > > Edition/ > > $ MESA_LOADER_DRIVER_OVERRIDE=i965 ./runner.sh Oh, nvm my comment, I misread your comment thinking you were referring to the `LIBGL_ALWAYS_SOFTWARE` variable
(In reply to Konstantin from comment #0) > After upgrading Fedora 33→34 on Macbook 2013, game "Divinity Original Sin > Enhanced Edition" always crashes on start with stacktrace: > > (0) /usr/lib/libpthread.so.0 : +0x13870 [0x7fd082419870] > (1) ./libOGLBinding.so : api::OpenGLRenderer::ApplyConstants()+0x65 > [0x7fd082d91845] Since the crash occurs in game code, the immediate cause is most likely a game bug. That said: > I tried building XWayland myself to bisect it further, but I can't seem to > get it to work with Gnome [...]. I suppose Fedora might have carried some > mandatory patches, so just trying to bisect upstream won't work here. I think it should be possible. What exactly was the problem with GNOME? It would be interesting to know which Xwayland change triggered the crash. One thing that comes to mind is that the newer Xwayland supports MSAA capable GLX visuals / FBConfigs.
> I think it should be possible. What exactly was the problem with GNOME? Hmm, actually mutter in F34 probably uses some Xwayland command line parameters which the old Xwayland didn't support yet. You'd need to use mutter built against Xwayland 1.20.z as well.
The issue seems to start with https://gitlab.freedesktop.org/xorg/xserver/-/commit/846924159 But the good news is that it works with https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/664
I've spawned a scratch build for you to test if you will: https://koji.fedoraproject.org/koji/taskinfo?taskID=71759435 Being a scratch build, it will be removed shortly, so please make sure to grab it while it's hot…
(In reply to Olivier Fourdan from comment #18) > I've spawned a scratch build for you to test if you will: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=71759435 > > Being a scratch build, it will be removed shortly, so please make sure to > grab it while it's hot… Oh, this is amazing, thank you very much for bisection and the package! I downloaded the package locally, will be able to test it 2 days once my gf is coming back (I tried to test it on my system as well, but apparently I can't just swap Archlinux XWayland binary with the one from Fedora and expect it to work, so gotta wait for a bit).
(In reply to Olivier Fourdan from comment #18) > I've spawned a scratch build for you to test if you will: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=71759435 > > Being a scratch build, it will be removed shortly, so please make sure to > grab it while it's hot… Amazing, thank you very much, I confirm it works! FTR: I tested it by unpacking the package and copying its Xwayland binary over the system one. I couldn't install the package as is due to `rpm` complaining: file /usr/bin/Xwayland from install of xorg-x11-server-Xwayland-21.1.2-1.1test.fc34.x86_64 conflicts with file from package xorg-x11-server-Xwayland-21.1.2-1.fc34.x86_64
(In reply to Konstantin from comment #20) > FTR: I tested it by unpacking the package and copying its Xwayland binary > over the system one. I couldn't install the package as is due to `rpm` > complaining: Just use: $ rpm -Fvh xorg-x11-server-Xwayland-21.1.2-1.1test.fc34.x86_64.rpm to upgrade the package (and not install the new one over the old one).
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.
If you want to boost your game at Lost Ark, a Game Boosting Service https://boosthive.eu/lost-ark can help you achieve this goal. These services do not use cheat engines or hacks but trick the game into thinking that you were playing it all along. However, you need to be careful while choosing a Game Boosting Service. Make sure you read the testimonials of users to make sure that you're dealing with an honest service.
https://ggboost.com is the leading boosting platform for gaming, offering lol boost and valorant boost services to help players get ahead.