search

SimonN / LixD

Lix: Lemmings-like game with puzzles, editor, multiplayer
https://www.lixgame.com
132 stars 17 forks source link

Debian 11, Lix 0.9.29 crashes when clicking 2nd replay #461

Closed ghost closed 5 months ago

ghost commented 1 year ago

OS: Debian GNU/Linux 11 (bullseye) x86_64

How to reproduce:

Go to replays Select a replay Select another replay(core dumped occurs here)

I don't know how to provide game logs if there are any

SimonN commented 1 year ago

Thanks for the report!

I've tried to reproduce this, but haven't seen Lix crash yet. I've tried to reproduce this in 0.10.9 (current stable) and 0.9.29 (what Debian 11 packages) and, just to make sure, also 0.9.24 (what Debian 10 packaged). I've only tested on Arch x64 (Lix doesn't crash here) and I don't have a Debian 11 x64 ready to test.

Game logs are in <Lix's directory>/user/log.txt, and Lix's directory is either ~/.local/share/lix if you've installed Lix from the package manager, or Lix's root directory (that contains src/) if you've downloaded the source and compiled Lix yourself. I doubt that you'll find a good log entry when Lix dumps core, but it's worth a try.

Next ideas:

  1. Which exact version of Lix are you running? Lix shows its version number in the main menu.

  2. Does Lix always crash when you click on a second replay? Can the second replay be any replay, or is it always a particular replay? If it's a particular replay, you can attach the replay file here. (You'll find the file in <Lix's directory>/replays/.)

  3. Have you compiled Lix yourself? In this case, I can walk you through building a debugging version of Lix, and run it with a debugger attached, to pinpoint where exactly Lix crashes.

ghost commented 1 year ago

Thank you for your quick response.

  1. Lix version is 0.9.29
  2. The second replay can be any replay
  3. I've used the Lix provided by Debian

Logs are in the attachments log.txt

SimonN commented 1 year ago

Thanks, the log doesn't show anything relevant.

Lix 0.9.29 didn't crash for me on Arch x64, but it does for you on Debian 11 x64. It's theroetically possible that you run out of RAM or VRAM, but you always crash exactly on clicking on the second replay, hmmm. Can you successfully play, e.g., 5 different levels from the singleplayer browser? Then I wouldn't suspect lack of system resources.

A more promising possibility is that the crash comes from interplay between Lix and one of Lix's runtime dependencies. You'll certainly be on other versions of the dependencies, and sometimes on other dependencies altogether than I am. (For example, I know about a crash in one of the Mesa 23.0.x libraries that happened reliably on exiting Lix. But this crash happened only on my notebook, it doesn't happen on my desktop despite identical Mesa versions. I've downgraded the notebook to Mesa 22.x.x, and the problem went away.)

Ideally, I should set up a Debian 11 x64 installation for myself. I'll make up my mind about setting up a virtual machine, or getting a used computer for exactly these kinds of experiments. I'll be busy for 1-2 weeks, but I'll let you know once I have something.

Do you have the debugger GDB installed? Even though you have a release build of Lix, might get rudimentary info whether the crash comes from Lix itself or from a dependency.

  1. Run: $ gdb lix -ex run
  2. Lix will appear. Reproduce the crash.
  3. Copy GDB's output to a text editor.
  4. Type at GDB's prompt: bt
  5. Copy any extra output to the text editor.
  6. To exit, type at GDB's prompt: q
  7. Post here what you've copied.

In addition, I can walk you through installing a D development environment, to build a debugging Lix version from source. But that's trickier on Debian because you'll have to add the D Language APT repository first, and only then follow my Linux build instructions. Let's see if we get somewhere first without building a debugging version from source.

ghost commented 1 year ago 

Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from lix...
(No debugging symbols found in lix)
Starting program: /usr/games/lix
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff5bfa700 (LWP 3745)]
[New Thread 0x7ffff53f9700 (LWP 3746)]
[New Thread 0x7fffebf17700 (LWP 3747)]
[New Thread 0x7fffeb5c1700 (LWP 3748)]
[New Thread 0x7fffeadc0700 (LWP 3749)]
[New Thread 0x7fffea5bf700 (LWP 3750)]
[New Thread 0x7fffe9dbe700 (LWP 3751)]
[New Thread 0x7fffe8df8700 (LWP 3752)]
[New Thread 0x7fffbbfff700 (LWP 3753)]
[New Thread 0x7ffff450a700 (LWP 3754)]
[New Thread 0x7ffff4500700 (LWP 3755)]
[New Thread 0x7ffff44f6700 (LWP 3756)]
--Type <RET> for more, q to quit, c to continue without paging--

Thread 1 "lix" received signal SIGSEGV, Segmentation fault.
0x00007ffff7937b50 in _d_interface_cast () from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.94
(gdb) bt
#0  0x00007ffff7937b50 in _d_interface_cast () from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.94
#1  0x00005555556017e8 in ?? ()
#2  0x000055555560171b in ?? ()
#3  0x00005555555e0605 in ?? ()
#4  0x000055555562093f in ?? ()
#5  0x0000555555619195 in ?? ()
#6  0x000055555560390f in ?? ()
#7  0x0000555555653f39 in ?? ()
#8  0x0000555555653f39 in ?? ()
#9  0x00005555556014c9 in ?? ()
#10 0x000055555564323a in ?? ()
#11 0x000055555571c087 in ?? ()
#12 0x0000555555623c6a in ?? ()
#13 0x00005555556238d3 in ?? ()
#14 0x00005555557373e8 in ?? ()
#15 0x000055555562309b in ?? ()
#16 0x00007ffff793a07c in rt.dmain2._d_run_main2(char[][], ulong, extern(C) int(char[][]) function).runAll() ()
   from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.94
#17 0x00007ffff7939e98 in _d_run_main2 () from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.94
#18 0x00007ffff7939cee in _d_run_main () from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.94
#19 0x00007ffff7526d0a in __libc_start_main (main=0x555555623dc0, argc=1, argv=0x7fffffffdeb8, init=<optimized out>,
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdea8) at ../csu/libc-start.c:308
#20 0x00005555555e029a in ?? ()```
SimonN commented 1 year ago

Thanks, this is more helpful than I imagined. I can rule out any external dependencies such as graphics drivers, version of Allegro 5, ..., and I consider the crash to happen from an interplay between Lix 0.9.29 and your exact version of the LDC D runtime.

Reason: The call stack has only addresses 0x000055555....., which have to be Lix itself, and 0x00007ffff79..., which, as the debugger tells us, is the LDC D runtime. When we crash, we are not calling into another library (such as Allegro 5). I believe it's possible to trigger segfaults in _d_interface_cast with a bug in usercode, thus it's possible that 0.9.29 really has a bug, and the bug merely doesn't trigger for me because I have a newer LDC.

I think the best way forward is for me to set up an environment with your exact LDC version and LDC runtime. I'll see when I have time; I won't have time this week for that.

ghost commented 1 year ago

I tried building the game from source and it doesn't happen. Probably it only happens for the debian version

SimonN commented 1 year ago

Thanks for rebuilding from source and confirming that your self-built version doesn't crash! Happy to hear that you've found a good solution. Enjoy!

I assume you've built 0.10.9.

I'll keep this bug in my mind, and would like to investigate the crash myself. Then I can make a better recommendation for the Debian packaging: Update Lix, update LDC, or possibly let me to hotfix Lix 0.9.x even though that's extra work. I'll see.

SimonN commented 1 year ago

@alexmyczko: This crash (only on Debian 11) is annoying enough to fix it in Debian 12, possibly even in Debian 11. It's too late to change Lix in time for Debian 12's Full Freeze on 2023-05-24, and apparently Debian 12 will ship Lix 0.9.29 again. But there is a chance that the newer LDC 1.30 will already fix the issue; Debian 11 ships only LDC 1.24.

I'll eventually try to run Debian 11 and Debian 12 in virtual machines, and reduce the bug myself.

alexmyczko commented 1 year ago

I guess we're too late for Debian 12, but a backport should be possible once we get to build the latest version built and uploaded.

Here's the bugs we collected so far: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=lix

and the build log with the latest version: http://sid.ethz.ch/debian/lix/2023/

Indeed with ldc2 we have: LDC - the LLVM D compiler (1.30.0):

Don't bother with hotfixes, I guess it would be best to package the latest version, and then backport to Debian 12 if anyone requests it. As Debian 12 will be out next month, you probably don't want to try to support Debian 11 anymore with it.

SimonN commented 1 year ago

Don't bother with hotfixes, I guess it would be best to package the latest version, and then backport to Debian 12 if anyone requests it.

All right, good plan. I can avoid the hotfixing then.

I'll keep this bug open until I've reproduced it on Debian 11.

The logfile lix_0.10.9-1_amd64.build looks like dub had trouble already during the fetch step. Feel free to open a separate bug to troubleshoot that build, or ask me or Lucki (Arch maintainer) in IRC (Quakenet #lix).

SimonN commented 5 months ago

Closing this because I won't reproduce it anytime soon on Debian 11. The current Debian is Debian 12. If Lix 0.10.x builds fine from source there, I'm happy.

If somebody else still would like to investigate this bug (an outdated Lix on an outdated Debian), I'll nonetheless be happy to assist.