Spring RTS Engine

Hi... I'm using Spring on linux (amd64, 64bit Spring compiled from 74.b3 branch in svn)

from time to time spring completely locks up - i've got no clue what could be the cause.

I compiled spring with debugging infos, attached gdb to get the bt when it is locked up:

(gdb) bt
#0 0x0000003003edb548 in ?? () from /lib/libc.so.6
#1 0x0000003003e741d2 in ?? () from /lib/libc.so.6
#2 0x0000003003e73261 in free () from /lib/libc.so.6
#3 0x0000003362e11309 in ?? () from /usr/lib/libSDL-1.2.so.0
#4 0x0000003362e11351 in SDL_WaitThread () from /usr/lib/libSDL-1.2.so.0
#5 0x0000003362e55241 in ?? () from /usr/lib/libSDL-1.2.so.0
#6 0x0000003362e11a57 in ?? () from /usr/lib/libSDL-1.2.so.0
#7 0x0000003362e08725 in SDL_QuitSubSystem () from /usr/lib/libSDL-1.2.so.0
#8 0x0000003362e0876e in SDL_Quit () from /usr/lib/libSDL-1.2.so.0
#9 0x0000003362e08f9f in ?? () from /usr/lib/libSDL-1.2.so.0
#10 <signal handler called>
#11 0x0000003003e6f483 in ?? () from /lib/libc.so.6
#12 0x0000003003e7326c in free () from /lib/libc.so.6
#13 0x000000300b2a150a in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string () from /usr/lib/libstdc++.so.6
#14 0x0000000000581683 in ~CommandDescription (this=0xaa32e98) at rts/Game/command.h:100
#15 0x00000000005817ed in std::_Destroy<CommandDescription> (__pointer=0xaa32e98)
at /usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:107
#16 0x000000000058180b in std::__destroy_aux<CommandDescription*> (__first=0xaa32e98, __last=0xaa32f48)
at /usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:122
#17 0x0000000000581840 in std::_Destroy<CommandDescription*> (__first=0xaa326b0, __last=0xaa32f48)
at /usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:155
#18 0x0000000000581863 in std::_Destroy<CommandDescription*, CommandDescription> (__first=0xaa326b0,
__last=0xaa32f48)
at /usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:182
#19 0x0000000000581d74 in ~vector (this=0x763b310)
at /usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_vector.h:272
#20 0x0000000000795f27 in ~CCommandAI (this=0x763b2a0) at rts/Sim/Units/CommandAI/CommandAI.cpp:256
#21 0x0000000000785977 in ~CFactoryCAI (this=0x763b2a0) at rts/Sim/Units/CommandAI/FactoryCAI.cpp:96
#22 0x000000000075b296 in ~CUnit (this=0x77d73c0) at rts/Sim/Units/Unit.cpp:213
#23 0x00000000007c7172 in ~CBuilding (this=0x77d73c0) at rts/Sim/Units/UnitTypes/Building.cpp:48
---Type <return> to continue, or q <return> to quit---
#24 0x00000000007c5195 in ~CFactory (this=0x77d73c0) at rts/Sim/Units/UnitTypes/Factory.cpp:54
#25 0x000000000077e36b in CUnitHandler::Update (this=0x5a0b7a0) at rts/Sim/Units/UnitHandler.cpp:206
#26 0x00000000005a3138 in CGame::SimFrame (this=0x15967d0) at rts/Game/Game.cpp:1893
#27 0x00000000005a4afd in CGame::ClientReadNet (this=0x15967d0) at rts/Game/Game.cpp:2304
#28 0x00000000005a78d8 in CGame::Update (this=0x15967d0) at rts/Game/Game.cpp:1470
#29 0x00000000004df9d7 in SpringApp::Update (this=0x7fffadbaaf90) at rts/System/Main.cpp:812
#30 0x00000000004e2eab in SpringApp::Run (this=0x7fffadbaaf90, argc=2, argv=0x7fffadbab0f8)
at rts/System/Main.cpp:990
#31 0x00000000004e2ff8 in Run (argc=2, argv=0x7fffadbab0f8) at rts/System/Main.cpp:1047
#32 0x00000000004e317f in main (argc=2, argv=0x7fffadbab0f8, envp=0x7fffadbab110)
at rts/System/Main.cpp:1087

---
i'm not perfectly sure...
from what i can guess looking at the Bt, something goes wrong when freeing that CommandDescription and SDL insists on waiting for some Thread in the Signal handler (i assume signal 11)

p (*(CommandDescription*)0xaa32e98)
$5 = {id = -353, type = 0, action = {static npos = 18446744073709551615,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x92203d8 "buildunit_corwolv"}}, hotkey = {static npos = 18446744073709551615,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x300b4f3e18 ""}}, name = {static npos = 18446744073709551615,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x460fa88 "corwolv"}}, iconname = {static npos = 18446744073709551615,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x300b4f3e18 ""}}, mouseicon = {static npos = 18446744073709551615,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x300b4f3e18 ""}}, tooltip = {static npos = 18446744073709551615,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
_M_p = 0x92205e8 "Build: Wolverine Light Mobile Artillery\nHealth 550\nMetal cost 159\nEnergy cost 2219 Build time 3254"}}, showUnique = false, onlyKey = false, onlyTexture = false,
params = {<std::_Vector_base<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >> = {
_M_impl = {<std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >> = {<__gnu_cxx::new_allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >> = {<No data fields>}, <No data fields>}, _M_start = 0x9dbe110, _M_finish = 0x9dbe110,
_M_end_of_storage = 0x9dbe110}}, <No data fields>}}


- but i doubt theres something wrong with the object.

Any idea what could be the cause of this 'crash' ?

It's not reproducible by executing the demo of that game.. but it might be that the final frame(s) haven't been written to the file by the time of the crash?

apart from that:

OpenGL renderer string: GeForce 6100 nForce 430/PCI/SSE2
OpenGL version string: 2.1.0 NVIDIA 96.31

Very interesting. A friend of mine has a similar problem. But with the regular Windows version.

In midgame all graphics freezes but he is still connected to the server and can still chat. But his entire screen is still. He is also able to give away his stuff to a teammate.

I dont have a clue whats the cause of this. But its very annoying.

No, thats not that similar... in my case the screen absolutely freezes - no updates are done anymore.

If i switch to desktop and back to spring, the spring screen will remain completely black. And i didn't suceed in issueing commands...

I get the same thing as you Scram80, but I always thought it was because of the crappy linux ATI drivers so I never bothered to report.

Also, how do you "switch to desktop and back to spring"? I didn't think minimising a full screen game was possible with x-server. I would love to know how you can do it.

Oh. i let spring run in windowed mode and tell the window manager to enlarge it to fullscreen (not maximising but fullscreen)

in gnome (both with metacity and beryl) you can configure it to a keybinding (from System|Settings|Key Combinations) - so i press ctrl+enter when spring loads up, the window frame vanishes and i get fullscreen spring... But still i can do alt-tab and switch virtual desktop.

KDE should be able to do the same

Scram80 wrote:Oh. i let spring run in windowed mode and tell the window manager to enlarge it to fullscreen (not maximising but fullscreen)

in gnome (both with metacity and beryl) you can configure it to a keybinding (from System|Settings|Key Combinations) - so i press ctrl+enter when spring loads up, the window frame vanishes and i get fullscreen spring... But still i can do alt-tab and switch virtual desktop.

KDE should be able to do the same

Thanks, I didn't know you could do that.

Edit:I works great, thanks again.

(gdb) bt
#0 0x0000003003edb548 in __lll_mutex_lock_wait () from /lib/libc.so.6
#1 0x0000003003e741d2 in _L_lock_14480 () from /lib/libc.so.6
#2 0x0000003003e73261 in free () from /lib/libc.so.6
#3 0x0000003362e11309 in ?? () from /usr/lib/libSDL-1.2.so.0
#4 0x0000003362e11351 in SDL_WaitThread () from /usr/lib/libSDL-1.2.so.0
#5 0x0000003362e55241 in ?? () from /usr/lib/libSDL-1.2.so.0
#6 0x0000003362e11a57 in ?? () from /usr/lib/libSDL-1.2.so.0
#7 0x0000003362e08725 in SDL_QuitSubSystem () from /usr/lib/libSDL-1.2.so.0
#8 0x0000003362e0876e in SDL_Quit () from /usr/lib/libSDL-1.2.so.0
#9 0x0000003362e08f9f in ?? () from /usr/lib/libSDL-1.2.so.0
#10 <signal handler called>
#11 0x0000003003e6fd05 in _int_malloc () from /lib/libc.so.6
#12 0x0000003003e7198d in malloc () from /lib/libc.so.6
#13 0x000000300b2c09bd in operator new () from /usr/lib/libstdc++.so.6
#14 0x00000000007b77c3 in CCobInstance::AddAnim (this=0x7a54f80,
type=CCobInstance::ATurn, piece=11, axis=0, speed=0, dest=-11466, accel=0,
interpolated=true) at rts/Sim/Units/COB/CobInstance.cpp:431
#15 0x00000000007b7a46 in CCobInstance::Turn (this=0x7a54f80, piece=11,
axis=0, speed=0, destination=-11466, interpolated=true)
at rts/Sim/Units/COB/CobInstance.cpp:504
#16 0x00000000007b7b3e in CCobInstance::TurnSmooth (this=0x7a54f80, piece=11,
axis=0, destination=-11466, delta=80, deltaTime=33)
at rts/Sim/Units/COB/CobInstance.cpp:1150
---Type <return> to continue, or q <return> to quit---
#17 0x00000000007ac1bc in CCobThread::CommitAnims (this=0x96aad30,
deltaTime=33) at rts/Sim/Units/COB/CobThread.cpp:788
#18 0x00000000007bb23b in CCobEngine::Tick (this=0xd9ff00, deltaTime=33)
at rts/Sim/Units/COB/CobEngine.cpp:149
#19 0x00000000005a3197 in CGame::SimFrame (this=0x1598ab0)
at rts/Game/Game.cpp:1902
#20 0x00000000005a4afd in CGame::ClientReadNet (this=0x1598ab0)
at rts/Game/Game.cpp:2304
#21 0x00000000005a78d8 in CGame::Update (this=0x1598ab0)
at rts/Game/Game.cpp:1470
#22 0x00000000004df9d7 in SpringApp::Update (this=0x7fff2efdb810)
at rts/System/Main.cpp:812
#23 0x00000000004e2eab in SpringApp::Run (this=0x7fff2efdb810, argc=2,
argv=0x7fff2efdb978) at rts/System/Main.cpp:990
#24 0x00000000004e2ff8 in Run (argc=2, argv=0x7fff2efdb978)
at rts/System/Main.cpp:1047
#25 0x00000000004e317f in main (argc=2, argv=0x7fff2efdb978,
envp=0x7fff2efdb990) at rts/System/Main.cpp:1087


-. different stacktrace though this time., same simptoms.

Might it be an SDL issue?