connection/freeze problems with 3.5.1

[titi]

We played a lot with 3.5.1 now and the (multiplayer)games are much better now than before, but we often have problems to start.
there are two problems which are !maybe! related.

1.Freeze of linux servers while clients connect:
We still don't found out what exactly happens, but this is the current state:
I open a server on linux and many people can connect without problems, but we found 2 players now where things go wrong.
If they connect the linux server freezes instantly and only the musik is playing in background. You have to kill -9 MG to stop the server!
update: brainbug was the players name! If he shows up its very easy to reproduce this problem. But as I said we had another newbie too who caused the same trouble.

2. disconnects on game start:
For whatever reason there are some people which very often get disconnected directly when the game starts. We also saw this for ultifd but he had to do something special to cause it. he connects to the server and changes the slot. If you now start the game he nearly always got disconnected when the game starts. ( We still have no log files for this, but we should really try to get them . This also only happened with linux/windows yet, bud this is maybe just bad luck )

But as I said, none of these problems show up once the game started.

[tomreyn]

To my knowledge, the latter issue only occurred for Derek (besides the variant (?) of this issue titi describes for Ultifd). About 50% of the times when we played a multi-player game with ~6 humans which I was hosting (on 64 bit Linux), Derek, the only Windows 7 64 bit SP0 player who connected (there was one other Windows player, he was on Vista 32 bit) got disconnected immediately after the game started. He got the message "the server has disconnected" and I + everyone else got the message "Derek left the game", as if it had been completely voluntarily. The other 50% when Derek could play, there were no related issues, no high latencies etc, so it doesn't seem to be an issue with Dereks' network connectivity being unreliable.

I also tried to get network and standard debug logs twice and ran with --verbose, but this issue of Derek dropping immediately after the start of the game did not occur then. So it might be timing related.

[ultifd]

I'll try to get a debug log, this happened to TotalNoob and I a lot yesterday.

[titi]

There is also an error message for the clients . an you please provide the exact error message?

[ultifd]

Erroraditionalbytes=-1
I already told softcoder, but I can't reproduce it with his server. He made a fix but I need someone else to test it with...hint* hint*

[softcoder]

Should be fix in svn now, we need to test these latest updates and release another update if everything is ok.

[tomreyn]

This happened earlier when Johnnyboy5566, the guy with the McAffee firewall which disrupts outbound TCP connections to non-whitelisted ports, connected to my 3.5.1 host:

Code: [Select]

Server: v3.5.1-GNUC: 40401 [64bit]-Rev: 2252
Client: v3.5.1-VC++: 1500-Rev: 2252M player [newbie]
In [/home/softcoder/Code/megaglest/trunk/source/glest_game/main/main.cpp::handleSIGSEGV Line: 568] Error detected: signal 11:
[2011-05-18 01:14:05] *ERROR* In [/home/softcoder/Code/megaglest/trunk/source/glest_game/main/main.cpp::handleRuntimeError Line: 344] [In [/home/softcoder/Code/megaglest/trunk/source/glest_game/main/main.cpp::handleSIGSEGV Line: 568] Error detected: signal 11:
] gameInitialized = 1, program = 0x286d890

0x00007f5ae16c77c4 in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
#0  0x00007f5ae16c77c4 in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007f5ae16c25cf in _L_lock_1005 () from /lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00007f5ae16c242b in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0
#3  0x00007f5ae192948e in SDL_mutexP () from /usr/lib/libSDL-1.2.so.0
#4  0x00000000008a79bc in Shared::Platform::Mutex::p (this=0x7f5ac803f0d8) at /home/softcoder/Code/megaglest/trunk/source/shared_lib/sources/platform/sdl/thread.cpp:117
#5  0x000000000076dc70 in Lock (this=<value optimized out>, mapSlotSignalledList=<value optimized out>, errorMsgList=..., eventList=<value optimized out>) at /home/softcoder/Code/megaglest/trunk/source/glest_game/../shared_lib/include/platform/sdl/thread.h:124
#6  MutexSafeWrapper (this=<value optimized out>, mapSlotSignalledList=<value optimized out>, errorMsgList=..., eventList=<value optimized out>) at /home/softcoder/Code/megaglest/trunk/source/glest_game/../shared_lib/include/platform/sdl/thread.h:97
#7  Glest::Game::ServerInterface::checkForCompletedClients (this=<value optimized out>, mapSlotSignalledList=<value optimized out>, errorMsgList=..., eventList=<value optimized out>) at /home/softcoder/Code/megaglest/trunk/source/glest_game/network/server_interface.cpp:629
#8  0x000000000077855d in Glest::Game::ServerInterface::update (this=0x7f5ac803edd0) at /home/softcoder/Code/megaglest/trunk/source/glest_game/network/server_interface.cpp:860
#9  0x0000000000658066 in Glest::Game::Program::loopWorker (this=0x286d890) at /home/softcoder/Code/megaglest/trunk/source/glest_game/main/program.cpp:316
#10 0x0000000000652605 in Glest::Game::glestMain (argc=<value optimized out>, argv=<value optimized out>) at /home/softcoder/Code/megaglest/trunk/source/glest_game/main/main.cpp:2928
#11 0x0000000000653944 in Glest::Game::glestMainWrapper (argc=1, argv=0x7fff58a203b8) at /home/softcoder/Code/megaglest/trunk/source/glest_game/main/main.cpp:3012
#12 0x00007f5add216eff in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#13 0x0000000000574289 in _start () at ../sysdeps/x86_64/elf/start.S:113

The game froze and I needed to kill -9 it. Does this look like the already fixed (in SVN) networking issue, or is it another one?

[softcoder]

This is definately not the svn code as the lines do not match what i have so it would be hard to trace this.

[tomreyn]

That's correct, it's not SVN code, it's 3.5.1 release code (as I wrote). I'm just trying to get your confirmation that this bug it most likely the same which was already fixed in SVN. Since if it is not, it could be another bug which is not yet fixed in SVN.