Open Try opened 9 months ago
I tested the following artifact on my PC: https://ci.appveyor.com/project/Try/opengothic/builds/48446975/job/i69kf1nsnjdggeyq/artifacts
System: Arch Linux x64 Kernel 6.5.7-arch1-1 Wayland
I did not get any sigkills (I started a game, talked to Xardas and walked around the tower a bit)
stdout:
~/Games/opengothictest
❯ ./Gothic2Notr.sh -g ~/.local/share/Steam/steamapps/common/Gothic\ II
OpenGothic v
no *.ini file in path - using default settings
GPU = AMD Radeon RX 6900 XT (RADV NAVI21)
Depth format = Depth32F Shadow format = Depth16
[ALSOFT] (EE) available update failed: Broken pipe
not implemented call [PERC_SETRANGE]
[phoenix] world: parsing object [MeshAndBsp % 0 0]
[phoenix] bsp_tree: parsing chunk c000
[phoenix] bsp_tree: parsing chunk c010
[phoenix] bsp_tree: parsing chunk c040
[phoenix] bsp_tree: parsing chunk c045
[phoenix] bsp_tree: parsing chunk c050
[phoenix] bsp_tree: parsing chunk c0ff
[phoenix] mesh: 1 bytes remaining in section b020
[phoenix] world: parsing object [VobTree % 0 0]
[phoenix] world: parsing object [WayNet % 0 0]
[phoenix] world: parsing object [EndMarker % 0 0]
invalid particle system: "INVISIBLE_VOBBOX.3DS"
unable to load sound fx: ENV_NIGHT_TONSOFINSECTS
unable to load sound fx: OW_BIRD11
[phoenix] model_script: unexpected value for event_tag_type: " "
[phoenix] model_script: 4 bytes remaining in section f5a3
[phoenix] vm: accessing member "C_NPC.AIVAR" without an instance set
[phoenix] vm: accessing member "C_NPC.AIVAR" without an instance set
[phoenix] vm: accessing member "C_NPC.AIVAR" without an instance set
Edit: could it be an glibc issue?
~/Games/opengothictest
❯ ldd --version
ldd (GNU libc) 2.38
Copyright (C) 2023 Free Software Foundation, Inc.
could it be an glibc issue?
Not sure, mine is just a smidge older (at least until I upgrade to Fedora 39, haha). Should still be newer than the Ubuntu 20.04 worker version. This is what I have on Fedora 38 at the moment:
ldd (GNU libc) 2.37
Copyright (C) 2023 Free Software Foundation, Inc.
Can it be because executable was link against one version of libc, and at runtime picket up a different one?
For the record, when actively reproducing the issue, I get it with around 10-20% probability.
The glibc is essential and its authors put great efforts in keeping it backwards compatible. Linking to an old version of glibc is completely fine, even recommended - some software projects use build machines running very old distros such as CentOS 6 to have linked against so old glibc version that you can run the resulting binary basically on anything :) Ubuntu 20.04 packages glibc 2.31, so this shouldn't be an issue.
I don't know yet how to get some useful logs out of this to better pinpoint the culprit - gdb
doesn't show anything, neither does journalctl
nor dmesg
, not even auditctl
. Any tips?
I get SIGKILL almost immediately after running, the game doesn't even reach main menu
Are you using pipewire? I used to have a bug in Debug/RelWithDebug
mode with same behavior. My workaround was to disable pipewire in build options. But can't reproduce it now, neither with CI nor self built.
Yes indeed, Fedora runs on Pipewire, but then I'd expect my builds to get KILLed and the Ubuntu CI artifacts to work fine.
I suspect something is happening in kernel because of the sheer lack of available debug data.
I tried one of the latest builds on Debian 12 and it works fine for me.
Regarding Pipewire: I also use it for my audio stuff.
I've just tested on a Fedora live USB and there are no issues either. In other words, the builds actually seem to run everywhere just fine and don't need to be blocked just because of my machine being the exception.
I'm still unsure, if that indeed a one-off case with Fedora. Until we can acquire a stack-trace at least... @Nindaleth Afair game crashed with no call-stack, but can it help, if we build it in debug-mode on CI side?
@Try The unfortunate thing is that SIGKILL cannot be masked, trapped or otherwise handled (by design); the one thing that could help is instrumenting the binary so that each function call is logged (or something similar that doesn't require manually going through the whole game loading code) which would allow us to better pinpoint the issue.
But I'm not sure it's worth it - as long as it's just me (because I build my own binaries anyway and I'm not really affected). Another instance of Fedora worked well, it's not Fedora-wide either.
But I'm not sure it's worth it
Agree, we can return to this once there is more cases/info.
Changed ticket description: only packaging *.deb remain.
Need to add
*.deb
packaging to CI and test it.Older post:
Followup to https://github.com/Try/OpenGothic/pull/527
local Linux builds (RelDebug) seem to work fine, but same is not true for CI builds;
original message: https://github.com/Try/OpenGothic/pull/527#issuecomment-1793580265