Bug 1009637

Thank you very much for your bug report

(In reply to Boian Berberov from comment #0)
> UFO:AI consistently crashes now.  This started occurring a couple of months
> ago, but I don't know which is the last working version.

'a couple of months' is quite bad - and makes it quite difficult to narrow down what could cause it now.

What openSUSE Version are you playing this on? (I'm just installing it again and will try to reproduce - I'm using TUmbleweed)
 
> Steps to reproduce:
> - Start UFO:AI
> - Select "Single-Player"
> - Select "Skirmish"
> - Choose a map and "Start Game", I tested with the africa_small and a few
> others.

Thanks for the detailed descriptions to reproduce it - that will surely help I hope

> The game loads, and the screen announcing the map and "Victory Conditions"
> shows up.  You can move the map in the background and it renders fine with
> no errors or crashes with multiple graphics configurations.  One the Start
> button is pressed it crashes after a couple of seconds.
> 

> Error: Received signal 11.

That's the actual issue we need to narrow down. If you run this on a recent version of openSUSE, systemd-crashhandler should have intercepted it and produced a coredump.

You can cehck that with 'coredumpctl' - you should find ufoai there in the list of crashed tasks. If so, you can do:

coredumpctl gdb PID
(replace PID with the number found in the earlier coredumpctl command)

at the (gdb) prompt, type "bt" (don't forget to hit enter)

gdb MIGHT be asking you to install -debuginfo packages; follow the instructions given by gdb how to do it (you can copy the zypper command line produced) - then reproduce above steps, until no further debuginfo is missing.

Then copy the output of "bt" in a text file and attach it here for review.

Thread 1 "ufoai" received signal SIGSEGV, Segmentation fault.
0x00000000005070c0 in Item::getReactionFireWeaponType() const ()
Missing separate debuginfos, use: zypper install ufoai-debuginfo-2.5-3.7.x86_64
(gdb) bt
#0  0x00000000005070c0 in Item::getReactionFireWeaponType() const ()
#1  0x0000000000507dfc in Inventory::holdsReactionFireWeapon() const ()
#2  0x000000000043a260 in HUD_RightHandChangeListener(char const*, char const*, char const*, void*) [clone .part.27] ()
#3  0x00000000004c4b43 in Cvar_Set2(char const*, char const*, bool) ()
#4  0x00000000004c5a42 in Cvar_Set(char const*, char const*, ...) ()
#5  0x000000000040fb5c in CL_UpdateCharacterValues(character_s const*) ()
#6  0x0000000000429651 in CL_ActorSelect(le_s*) ()
#7  0x0000000000429a1d in CL_ActorSelectList(int) [clone .part.17] ()
#8  0x00000000004402be in CL_ActorAppear(eventRegister_s const*, dbuffer*) ()
#9  0x000000000043d50c in CL_ExecuteBattlescapeEvent(int, void*) ()
#10 0x00000000004c3c28 in Qcommon_Frame() ()
#11 0x000000000040af05 in main ()

(In reply to Dominique Leuenberger from comment #1)
> 'a couple of months' is quite bad - and makes it quite difficult to narrow
> down what could cause it now.

I assumed it was something with Mesa/DRI/graphics stack.  It usually is, but I doubt it now.  I am running Intel Sandy Bridge, but the way, but I also have and Optimus NVidia that should be disabled

'games' is not the main repo.  I was not sure how things are handled in OpenSUSE; if the bug would even be looked at.

In the end I was hoping you have a 'bisect-like' tool, if it was reproducible.

> What openSUSE Version are you playing this on? (I'm just installing it again
> and will try to reproduce - I'm using TUmbleweed)

I'm running Tumbleweed and it's updated weekly.  Will be updating tonight.

> That's the actual issue we need to narrow down. If you run this on a recent
> version of openSUSE, systemd-crashhandler should have intercepted it and
> produced a coredump.

I am not sure coredumps are produced, but I'll check.  I think that can be enabled.

> gdb MIGHT be asking you to install -debuginfo packages; follow the
> instructions given by gdb how to do it (you can copy the zypper command line
> produced) - then reproduce above steps, until no further debuginfo is
> missing.
> 
> Then copy the output of "bt" in a text file and attach it here for review.

I'll install the debuginfo packages and try to generate some kind of trace.

Created attachment 701723 [details]
UFO: AI generated crash report

This is a report UFO:AI generated itself, but could not send out ( I was offline ).

Sorry for the delay.

Didn't make a coredump, but ran it with GDB.  Got the same trace on version 2.5-3.48  Need to learn more GDB.

____________________________________________________________

(player 0) It's team 1's turn!
bberberov has taken control over team 1.

Thread 1 "ufoai" received signal SIGSEGV, Segmentation fault.
0x0000000000507130 in Item::getReactionFireWeaponType() const ()
(gdb) bt
#0  0x0000000000507130 in Item::getReactionFireWeaponType() const ()
#1  0x0000000000507e6c in Inventory::holdsReactionFireWeapon() const ()
#2  0x000000000043acb0 in HUD_RightHandChangeListener(char const*, char const*, char const*, void*) [clone .part.27] ()
#3  0x00000000004c4ba3 in Cvar_Set2(char const*, char const*, bool) ()
#4  0x00000000004c5aa2 in Cvar_Set(char const*, char const*, ...) ()
#5  0x000000000040b8dc in CL_UpdateCharacterValues(character_s const*) ()
#6  0x0000000000429641 in CL_ActorSelect(le_s*) ()
#7  0x0000000000429a0d in CL_ActorSelectList(int) [clone .part.17] ()
#8  0x000000000043f83e in CL_ActorAppear(eventRegister_s const*, dbuffer*) ()
#9  0x000000000043d50c in CL_ExecuteBattlescapeEvent(int, void*) ()
#10 0x00000000004c3c88 in Qcommon_Frame() ()
#11 0x000000000040af05 in main ()

This bug appears to be fixed, but the source archive in OBS needs to be updated.  It looks like there are no new releases.  Is it possible to build from a newer git commit instead?

Adding some more people that seem to care for this game.

It is no longer part of the openSUSE Tumbleweed channels (too unstable - upstream seems not to care much for releases anymore)

with ufo:ai no longer being part of the repositories, we have to consider this an 'upstream issue - likely never to be fixed'