Try / OpenGothic

Reimplementation of Gothic 2 Notr
MIT License
1.13k stars 81 forks source link

Productise Linux artifacts #532

Open Try opened 9 months ago

Try commented 9 months ago

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;

I get SIGKILL almost immediately after running, the game doesn't even reach main menu, there's just a little bit of log and for some reason even when running under gdb, there's no backtrace to see, nothing in the crashlog either

$ ./Gothic2Notr.sh -g ~/Games/gothic-ii-gold-edition/drive_c/GOG\ Games/Gothic\ 2\ Gold/
OpenGothic v
GPU = AMD Radeon RX 6700 XT (RADV NAVI22)
Depth format = Depth32F Shadow format = Depth16
Killed
$ DEBUGGER=gdb ./Gothic2Notr.sh -g ~/Games/gothic-ii-gold-edition/drive_c/GOG\ Games/Gothic\ 2\ Gold/ -v
(...)
(gdb) r
Starting program: /home/black_fox/Downloads/opengothic_linux/Gothic2Notr -g /home/black_fox/Games/gothic-ii-gold-edition/drive_c/GOG\ Games/Gothic\ 2\ Gold/ -v
(...)
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(...)
(gdb) bt
No stack.
(gdb)

original message: https://github.com/Try/OpenGothic/pull/527#issuecomment-1793580265

fhanrath commented 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.
Nindaleth commented 9 months ago

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.
Try commented 9 months ago

Can it be because executable was link against one version of libc, and at runtime picket up a different one?

Nindaleth commented 9 months ago

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?

thokkat commented 9 months ago

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.

Nindaleth commented 9 months ago

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.

Pio64 commented 9 months ago

I tried one of the latest builds on Debian 12 and it works fine for me.

fhanrath commented 9 months ago

Regarding Pipewire: I also use it for my audio stuff.

Nindaleth commented 9 months ago

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.

Try commented 8 months ago

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?

Nindaleth commented 8 months ago

@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.

Try commented 8 months ago

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.