Vega-strike-engine-source: Game crashes when paused, can't resume

[Echoes91]

Observed behaviour

When game is put in pause ('Pause' key) during flight it freezes and cannot be resumed.

Once killed:

Traceback (most recent call last):
  File "/home/andre/Build/Assets-Production/modules/missions/privateer.py", line 34, in Execute
    i.Execute()
  File "/home/andre/Build/Assets-Production/modules/random_encounters.py", line 291, in Execute
    dynamic_battle.UpdateCombatTurn()
  File "/home/andre/Build/Assets-Production/modules/dynamic_battle.py", line 42, in UpdateCombatTurn
    lookorsiege=LookForTrouble (fac)
  File "/home/andre/Build/Assets-Production/modules/dynamic_battle.py", line 369, in LookForTrouble
    randomMovement (i,faction)
  File "/home/andre/Build/Assets-Production/modules/dynamic_battle.py", line 275, in randomMovement
    fg_util.TransferFG( fg,fac,suggestednewsys);
  File "/home/andre/Build/Assets-Production/modules/fg_util.py", line 424, in TransferFG
    starsystem=Director.getSaveString(ccp,key,1)
KeyboardInterrupt
terminate called after throwing an instance of 'boost::python::error_already_set'

Expected behaviour

Game is put in pause and resumed with 'Pause' key

Vega Strike 0.5.3 (current master) on Arch Linux x86_64

[pyramid3d]

Can reproduce it on the same system (haven't tested others).
In the meantime you may want to dock with a planet or station to pause the game.

[LifWirser]

I ran into this problem on Debian 9 just going between two planets - didn't get traceback, I had a hard lockup on mine. Marking as BUG

Thank You

[bmorel]

Tried it, pausing made one CPU core going 100% use in USR mode. Breaking a gdb in that, I have an CPU burner loop in engine/src/gldrv/winsys.cpp. Might be an infinite loop, depending on if yes or no the switch on line 428 checks all possibilities (hint: it does not).

[stephengtuggy]

I have definitely seen this bug myself! Using the older (0.5.2?) code

[BenjamenMeyer]

I've got a few questions. This will help us evaluate this bug as we're trying to prioritize some work in order to release 0.6.0.

Question: Is this a bug with the assets or with the core engine?
Question: Can someone test this against current master?

Reason: We've removed and refactored some code on master. If that code is at fault then master should no longer exhibit this behavior; in which case we can file as a known issue for the 0.6.x branch and close as being fixed for the next release (0.7.x). If it's still an issue on master then we'v at least eliminated some code paths. It also leads to the next question...

Question: Is this something something vital to fix for 0.6.x? And do we have someone willing to track it down sufficiently to fix it for 0.6.x?

If there is no response in the next week, then I'm going to move the target fro 0.6.x to 0.7.x to extend the investigation timeline.

[nabaco]

According to Bmorel's reply above, this is an issue with the engine. We have a specific line of code to go to.
If I'll have time I'll try to tackle this bug.

[Echoes91]

Tried a fresh master build as of today and bug is still there, can't tell much more as I'm a total noob whith gdb and getting a different result everytime.

[nabaco]

Hi @Echoes91 thank you for checking. We'll try to address the issue ASAP.

[BenjamenMeyer]

I triggered this on master last night. Didn't have time to look into it but can also confirm.

[BenjamenMeyer]

Attached the console output from when I triggered the crash.
20200625_game-crash_brm.log

Notes:

• I paused during flight; game was in 32-bit windowed mode
• it seemed to get stuck in a loop regarding cannot execute suborders as Linear Velocity Matcher; I had seen that earlier without any effect. Though it might be that the paused game allowed it to get caught in a tight loop around that aspect of the game.
• music seemed to continue playing just fine
• I was unable to unpause the game so had to CTRL+C out; so it wasn't a hard crash in that the game itself aborted without user intervention but the game had essentially come to a stand-still that wasn't going to resolve itself.

This was while running master (at https://github.com/vegastrike/Vega-Strike-Engine-Source/commit/402ac075b6d2cd3c465a69974f7022cd67412c75) to do a confirmation test; the changes I was confirming were fine and this is unrelated to that test (conversion from cs_python.h to the normal Python.h headers).

[BenjamenMeyer]

Looking into this. Using these steps to reproduce:

• Start under gdb:

$ gdb ./vegastrike
> set args debug=3
> start
> c

• Select Campaign to start a brand new Campaign
• Launch
• Press Pause/break to pause the game
• Try to press Pause/break to unpause the game
• CTRL+C in the console to break to the debugger

[BenjamenMeyer]

This has been fixed on 0.6.x; we need the same fix applied to Master. So moving to 0.7.x as the target now and dropping from the 0.6.x project board.

[stephengtuggy]

I believe this issue is fixed in #161 . I just neglected to reference this issue in the pull request.

[BenjamenMeyer]

@stephengtuggy thanks; we'll close it then.