MegaGlest Forum
MegaGlest => Bug reports => Topic started by: tomreyn on 25 February 2013, 13:55:34
-
The "summoner" headless game server has vanished off the masterserver lately, so I inspected the situation on the server. I found the megaglest process still running. An attempt to connect to it from my computer failed, but it took quite a while until it did. The servers' log files contained this:
[2013-02-23 09:14:24] *ERROR* SOCKET WRITE TIMEOUT In [/srv/ci/workspace/megaglest-trunk_l64/source/shared_lib/sources/platform/posix/socket.cpp::isWritable Line: 1673] i = 0 sock = 8
[2013-02-23 09:14:24] *ERROR* SOCKET WRITE TIMEOUT In [/srv/ci/workspace/megaglest-trunk_l64/source/shared_lib/sources/platform/posix/socket.cpp::isWritable Line: 1673] i = 0 sock = 8
[2013-02-23 09:14:25] *ERROR* In [/srv/ci/workspace/megaglest-trunk_l64/source/glest_game/network/connection_slot.cpp::update Line: 1329] Error [Invalid message type: 81
Stack Trace:
./megaglest:Shared::Platform::megaglest_runtime_error::megaglest_runtime_error(std::string const&, bool)address [0xb49b1e] line: 237
./megaglest:Glest::Game::NetworkInterface::getNextMessageType()address [0x90d2cf] line: 72
./megaglest:Glest::Game::ConnectionSlot::update(bool, int)address [0x91b878] line: 591
./megaglest:Glest::Game::ConnectionSlot::updateSlot(Glest::Game::ConnectionSlotEvent*)address [0x923f25] line: 374
./megaglest:Glest::Game::ConnectionSlotThread::execute()address [0x9243cc] line: 225
./megaglest:Shared::Platform::Thread::beginExecution(void*)address [0xb3872f] line: 86
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0:()address [0x7fdcbe654fd5] line: 0
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0:()address [0x7fdcbe698999] line: 0
/lib/x86_64-linux-gnu/libpthread.so.0:()address [0x7fdcbe42ce9a] line: 0
/lib/x86_64-linux-gnu/libc.so.6:clone()address [0x7fdcbab29cbd] line: 0
]
[2013-02-23 09:14:25] *ERROR* In [network_interface.cpp::DisplayErrorMessage Line: 99] sErr [Invalid message type: 81
Stack Trace:
./megaglest:Shared::Platform::megaglest_runtime_error::megaglest_runtime_error(std::string const&, bool)address [0xb49b1e] line: 237
./megaglest:Glest::Game::NetworkInterface::getNextMessageType()address [0x90d2cf] line: 72
./megaglest:Glest::Game::ConnectionSlot::update(bool, int)address [0x91b878] line: 591
./megaglest:Glest::Game::ConnectionSlot::updateSlot(Glest::Game::ConnectionSlotEvent*)address [0x923f25] line: 374
./megaglest:Glest::Game::ConnectionSlotThread::execute()address [0x9243cc] line: 225
./megaglest:Shared::Platform::Thread::beginExecution(void*)address [0xb3872f] line: 86
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0:()address [0x7fdcbe654fd5] line: 0
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0:()address [0x7fdcbe698999] line: 0
/lib/x86_64-linux-gnu/libpthread.so.0:()address [0x7fdcbe42ce9a] line: 0
/lib/x86_64-linux-gnu/libc.so.6:clone()address [0x7fdcbab29cbd] line: 0
]
Message:
Invalid message type: 81
Stack Trace:
./megaglest:Shared::Platform::megaglest_runtime_error::megaglest_runtime_error(std::string const&, bool)address [0xb49b1e] line: 237
./megaglest:Glest::Game::NetworkInterface::getNextMessageType()address [0x90d2cf] line: 72
./megaglest:Glest::Game::ConnectionSlot::update(bool, int)address [0x91b878] line: 591
./megaglest:Glest::Game::ConnectionSlot::updateSlot(Glest::Game::ConnectionSlotEvent*)address [0x923f25] line: 374
./megaglest:Glest::Game::ConnectionSlotThread::execute()address [0x9243cc] line: 225
./megaglest:Shared::Platform::Thread::beginExecution(void*)address [0xb3872f] line: 86
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0:()address [0x7fdcbe654fd5] line: 0
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0:()address [0x7fdcbe698999] line: 0
/lib/x86_64-linux-gnu/libpthread.so.0:()address [0x7fdcbe42ce9a] line: 0
/lib/x86_64-linux-gnu/libc.so.6:clone()address [0x7fdcbab29cbd] line: 0
I have since rebooted this server, so this situation no longer persists.
-
This error may occur when players with earlier svn revisions connect to a server running the latest trunk revision. Filux had this happen to him yesterday when he was hosting and vlk and Derek connected (and I suspect both were running at least somewhat older revisions).
-
Then this is not a bug, its due to new network messages for resume game.
-
I understand that this can't be expected to work, both clients speak a different protocol and you can't expect them to be able to understand each other properly this way. However, at least to me, any issue which allows you to remotely crash a server (make the porcess die with a segfault) is a bug.
-
refresh
-
To clarify, this is only happening on development builds where the version is the same but the svn revision is different right? If that is the case I'm not sure if this is worth doing anything since how would we know the difference between bad network data from a rogue or corrupt client from an incompatible svn revision? Thios should not be able to occur for different versioned builds.
-
Yes, server and client were announcing the same version at the time, probably 3.8-dev. As such I can see how it can be considered a corner case - based on Softcoders' reply I think this will probably never affect releases, just development versions of servers. We should be aware, though, that this may also allow for targetted denial of service attacks with the goal to make some server unusable.
I'm not into network protocol design, but basically I would think that servers need to always ensure they will not be affected by any kind of unexpected / false information sent from a client. And that a version string sent by a client should be treated as no more than an indication. Compare this with web server or web application and User Agent string or Referer header. The web application should never rely on those to be correct, and an incorrect value there should not allow the server side to go into a state which prevents it from delivering service, and which it is unable to recover from.
Having said this, I still agree this is less serious and not urgent, since it seems unlikely that someone will want to exploit this anytime soon.