[noobspace]

I've been able to play a significant amount of FSO on Linux. However, I have started seeing segfaults:

Code: [Select]

segfault at 655cbcb92048 ip 000055773aa526f0 sp 00007fff9775b2c0 error 4 in fs2_open_21_4_0_x64
I'm not sure if there are log files anywhere that will help with debugging, but I'll be happy to find and upload any that there are!

[noobspace]

Saw another crash. Was able to gather more information:

Code: [Select]

Dec 27 14:59:07 nathanb-dev audit[3585588]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=3 pid=3585588 comm="fs2_open_21_4_0" exe="/tmp/.mount_fs2_opahzcnL/bin/fs2_open_21_4_0_x64" sig=11 res=1
Dec 27 14:59:07 nathanb-dev kernel: fs2_open_21_4_0[3585588]: segfault at 65480ed92048 ip 000055628cc526f0 sp 00007ffc919f5ae0 error 4 in fs2_open_21_4_0_x64[55628c600000+db5000]
Dec 27 14:59:07 nathanb-dev kernel: Code: 15 e5 52 02 01 85 c9 78 08 3b 8a 4c 1b 00 00 7e 0f 8b ba 50 1b 00 00 e8 1e 09 cb ff 84 c0 75 0a 48 83 c4 08 5b 5d c3 0f 1f 00 <8b> b3 a8 01 00 00 8b bd a8 01 00 00 e8 6f ff c9 ff 84 c0 74 e1 8b
Dec 27 14:59:07 nathanb-dev kernel: audit: type=1701 audit(1640635147.191:3890): auid=1000 uid=1000 gid=1000 ses=3 pid=3585588 comm="fs2_open_21_4_0" exe="/tmp/.mount_fs2_opahzcnL/bin/fs2_open_21_4_0_x64" sig=11 res=1
Dec 27 14:59:20 nathanb-dev systemd-coredump[3587049]: The core will not be stored: size 2147483648 is greater than 804257792 (the configured maximum)
Dec 27 14:59:20 nathanb-dev systemd-coredump[3587049]: [🡕] Process 3585588 (fs2_open_21_4_0) of user 1000 dumped core.
                                                       
                                                       Found module /tmp/.mount_fs2_opahzcnL/bin/fs2_open_21_4_0_x64 with build-id: 37cac4f4d2e0876f5aa3666333d9739bf8791340
                                                       Stack trace of thread 3585588:
                                                       #0  0x000055628cc526f0 n/a (/tmp/.mount_fs2_opahzcnL/bin/fs2_open_21_4_0_x64 + 0x6526f0)


And dmesg says:

Code: [Select]

[3543193.777343] fs2_open_21_4_0[3585588]: segfault at 65480ed92048 ip 000055628cc526f0 sp 00007ffc919f5ae0 error 4 in fs2_open_21_4_0_x64[55628c600000+db5000]
[3543193.777359] Code: 15 e5 52 02 01 85 c9 78 08 3b 8a 4c 1b 00 00 7e 0f 8b ba 50 1b 00 00 e8 1e 09 cb ff 84 c0 75 0a 48 83 c4 08 5b 5d c3 0f 1f 00 <8b> b3 a8 01 00 00 8b bd a8 01 00 00 e8 6f ff c9 ff 84 c0 74 e1 8b

I'm probably just shouting into the void here, but maybe if someone else has the same problem they can at least find this post via Google.

[jg18]

Hi there!

Can you provide steps to follow that reliably reproduce the crash? Ideally, repro steps use only FS2 retail assets without mods, unless the crash is tied to a specific mod.

Which Linux distro are you using? What distro version is it?

The log file is called fs2_open.log. I think that on Linux, the log file path is ~/.fs2_open/data/ but am not sure.

However, only Debug and FastDebug FSO builds produce these logs. I'm not sure what's involved in getting a debug FSO build on Linux. My guess is that you'll need to build FSO yourself. Have you done that before?

Also, we'll need to see a full stack trace. A debug (probably also FastDebug) FSO build should be able to provide that, but I think the instructions for getting a core dump/stack trace are distro-specific.

[noobspace]

Hi, thanks for the reply.

The crash seems to happen randomly. Where I see it happen the most is on the mission Bearbaiting. I am playing using the MediaVPS hi-res textures mod and the hi-res HUD assets mod. I can see if it happens with retail assets without mods. The crash occurs when the Sathanis jumps out if I am looking at it when it jumps. If I'm not looking at the ship when it jumps, the game does not crash.

I am using Arch Linux, which is a rolling release distro and doesn't have versions. I'm using the proprietary nVidia drivers.

I have not built FSO myself. I'll look into what's required to get a debug log. If you need a core dump I may need to reconfigure my system to allow larger corefiles, since I think the non-debug coredump is already over 2 GB.

[jg18]

The crash seems to happen randomly. Where I see it happen the most is on the mission Bearbaiting. I am playing using the MediaVPS hi-res textures mod and the hi-res HUD assets mod. I can see if it happens with retail assets without mods. The crash occurs when the Sathanis jumps out if I am looking at it when it jumps. If I'm not looking at the ship when it jumps, the game does not crash.

Thanks for finding a reliable repro. By "looking", does the crash occur if the Sathanas is anywhere in view? Or only if it's in your reticle? Or only if you have the Sathanas targeted? Does the crash occur if the Sathanas is targeted but out of view? If the crash occurs specifically when you have the ship targeted, does it occur if you have one of its turrets targeted? Or if you have one of its subsystems targeted?

Basically, the more precise you can be on when the crash does(n't) occur, the easier it'll be to track down, although you already have a good start.

To make repro faster, you might try speeding up the game (or as the FS2 manual says IIRC, "increase time compression"). I think the hotkey is > but I forget. However, I don't know if doing that will make repro less reliable.

I have not built FSO myself. I'll look into what's required to get a debug log. If you need a core dump I may need to reconfigure my system to allow larger corefiles, since I think the non-debug coredump is already over 2 GB.

I take it you're using the fs2_open-appimage AUR package? I don't know anything about package management in Arch, but is it possible to build the package with a Debug build configuration? If the game runs too slowly with a Debug build, try the FastDebug build configuration, which is defined in FSO's CMake scripts.

I don't know what's required to get a stack trace on Arch. Perhaps a core dump isn't required.

The only case I can think of offhand where a core dump might be useful is if having both fs2_open.log and a stack trace ends up not being enough info to figure out the root cause. In that case, it might help if you could inspect a core dump in GDB or similar for, e.g., values of local variables at the time of the crash. But hopefully we won't need to get into nitty gritty like that.

Thanks!

[noobspace]

I'll investigate the questions you asked. I updated and restarted my system to see if that would help, and the update process seems to have broken Knossos  . I'll figure that out and then return to debugging the original problem.

Speaking of knossos, I'm using the fs2_knossos package to run FSO. For the FS2 installation, I actually have the physical CDs from back when I originally bought the game at retail, so I pulled the relevant files off those, shoved them in a directory, and pointed Knossos at it. I'm still not entirely familiar with FS2 Open, Knossos, and how all these projects intertwine and interact.