SL201 / static linux64 98: end of game freeze

[albator]

1) after a game is over (as a player), spring cannot exit and I need to kill the process so that I can exit

2) after that, I want to play and even there is not game running (only the lobby), SL detect me as ingame so I need to restart it at each game

Code: Select all

ps -All | grep spring
206:0 S  1000 28611  2507  2  80   0 - 261896 poll_s ?       00:03:05 springlobby

Unfortunatly, the log file was erased, but the game is here: http://replays.springrts.com/replay/8a8 ... 668e74b03/

[albator]

It looks like the problem is correlated with the fact that SL201 launch spring as a job called: "unknowed"

Code: Select all

14699 me    20   0 1827628 1,021g  71108 S   5,0  8,7  93:20.92 unknown  

That may be a bug from SL201 then ?

[abma]

please provide infolog.txt.

no, thats no springlobby bug. you seem to have failed to kill the spring process, this is why springlobby shows you still ingame. (spring process running = status is set ingame)

[albator]

I finally got one:

http://replays.springrts.com/replay/06d ... 424db2128d


http://pastebin.com/AKpX1yTH

[abma]

"Loading widget from user"

are you sure it isn't caused by user widgets?

next time when it happens can you attach gdb to the thread and to a backtrace?

sth. like this:

find spring process id with

ps aux|grep spring
gdb -p <process id>
bt

and paste the output of bt here please

[abma]

more info why i assume this:

last output of shutdown is "[~CGame][6]" this is why it hangs after [~CGame][6] and before [~CGame][7]:
https://github.com/spring/spring/blob/d ... e.cpp#L464

which contains this:

Code: Select all

	SafeDelete(guihandler); // frees LuaUI

so could be a lua (user) widget which fails at shutdown.

[albator]

hum.. I have no extra widget installed, so that is probalby a widget that has been added/modified with the last BA (8.xx). ANy idea how I could test that ? The problem is that it is quite random so no way to know for sure which one it is if I was testing them one by one.

[Silentwings]

Your infolog above shows that you have 5 extra widgets installed. Since you are the only person to report this issue so far, it is more likely to be one of those than one of BAs internal widgets - you should test your user widgets first.

Code: Select all

[f=0000000] Loading widget from user:  Toggle LOS          <gui_toggleLos.lua> ...

[f=0000000] Loading widget from user:  Mobile anti defence range v5  <gui_mobile_anti_defence_range.lua> ...

[f=0000000] Loading widget from user:  Radar Ranges        <radar_range.lua> ...

[f=0000000] Loading widget from user:  Obedient constructors v3  <unit_obedient_constructors.lua> ...

[f=0000000] Loading widget from user:  Unit Stats          <gui_unit_stats.lua> ...

To investigate it from the widget side, probably the first thing I would try to do is add some debug printing and find out which one of these was most recently active when the crash occured.

A better way of approaching this would be to use gdb to supply a backtrace of the crash, using abmas instructions. You may need to do "thread apply all bt" instead of just "bt".

[albator]

Your infolog above shows that you have 5 extra widgets installed. Since you are the only person to report this issue so far, it is more likely to be one of those than one of BAs internal widgets - you should test your user widgets first.

Code: Select all

[f=0000000] Loading widget from user:  Toggle LOS          <gui_toggleLos.lua> ...

[f=0000000] Loading widget from user:  Mobile anti defence range v5  <gui_mobile_anti_defence_range.lua> ...

[f=0000000] Loading widget from user:  Radar Ranges        <radar_range.lua> ...

[f=0000000] Loading widget from user:  Obedient constructors v3  <unit_obedient_constructors.lua> ...

[f=0000000] Loading widget from user:  Unit Stats          <gui_unit_stats.lua> ...

To investigate it from the widget side, probably the first thing I would try to do is add some debug printing and find out which one of these was most recently active when the crash occured.

A better way of approaching this would be to use gdb to supply a backtrace of the crash, using abmas instructions. You may need to do "thread apply all bt" instead of just "bt".

How can there be extra widget installed since I am runining spring using static build ?

I also compile SL201 front source.

I configured both the bin and the so path in SL toward that static install

So how can it show extra widget while I configured those 2 paths correcly ?


EDIT:

I found out that SL201 just is not coherent with the path you indicate in the preference setting and still go for ~/.spring or ~/.config/spring

so that is a bug that should be fixed on SL side

[abma]

How can there be extra widget installed since I am runining spring using static build ?

I also compile SL201 front source.

I configured both the bin and the so path in SL toward that static install

So how can it show extra widget while I configured those 2 paths correcly ?

springlobby doesn't set any data path for spring, thats no bug. springlobby just doesn't touch springs config.

EDIT:

I found out that SL201 just is not coherent with the path you indicate in the preference setting and still go for ~/.spring or ~/.config/spring

so that is a bug that should be fixed on SL side

no, thats no bug, you are requesting a new feature. spring != springlobby. spring uses these paths!

check these paths for the widgets:

Code: Select all

Using read-write data directory: /home/pierre/Softwares/Games/98/
Using read-only data directory: /home/pierre/.config/spring/
Using read-only data directory: /home/pierre/.spring/

[albator]

springlobby doesn't set any data path for spring, thats no bug

I am not going to argue on that ...

but if you expect the lamba user who arrive in spring to configure so lib and bin and not even mentioning where the configuration is going to be taken, that is misleading imho. So I think that should be mentioned at the very same place where you configure that, in big red caracter so that the user knows that most of the directories in the static install are useless.
I think that is indeed fair to assume that a random player is not born with knowedge of spring config/path architecture if he wants to play (I actually still have no idea which directory are useful in the static install and where I should place my uitkey/settign files, widget, Config etc... / does that mean only so and bin are the only usefull files in the static dir ?

Also my static demo dir has some file in it, so it looks like the behavior you are mentioning is eratic. This look even more misleading. Sorry to look like an ass, but I remember TAS when I was playing on windows 5 years ago and I could play with different versions of spring using different mod and configuration all in static without problem. I am grateful there is a linux lobby though. Anyway thanks for the info it is not a bug.

[abma]

but if you expect the lamba user who arrive in spring to configure so lib and bin and not even mentioning where the configuration is going to be taken, that is misleading imho.

spring/springlobby doesn't except that. workflow is like this: install springlobby, join a game, click yes to allow springlobby to download game/map/engine -> done. no need to configure anything! only problem currently exists that springlobby is often very old in linux distributions.

for me it looks like you chose an other path.

[albator]

I am using Linux on mint (1st linux distrib since years: http://distrowatch.com/table.php?distribution=mint ).

The only pb is that SL is outdated on the repo and not compatible with spring anymore.