Anonymous | Login | 2024-11-21 09:48 CET |
Main | My View | View Issues | Change Log | Roadmap | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0000154 | Soldat Dedicated Server | General | public | 2012-02-08 23:26 | 2012-02-13 01:44 | ||||
Reporter | Mr | ||||||||
Assigned To | Shoozza | ||||||||
Priority | normal | Severity | block | Reproducibility | always | ||||
Status | resolved | Resolution | fixed | ||||||
Platform | x64 | OS | Windows | OS Version | 7 | ||||
Product Version | 2.7.2 | ||||||||
Target Version | Fixed in Version | 2.7.3 | |||||||
Summary | 0000154: Forcefully closing connection to admin server results in malfunction of admin server | ||||||||
Description | I've stumbled upon this issue quite a few times now while working on MSAC and a gather bot for #lrs, turns out it does not happen randomly: If an admin connection to the Soldat dedicated server is forcefully closed, new admin clients do not receive any more data after authenticating. The "Sever version: 2.7.2" line is the last line that is received. If there are players on the server, it sometimes randomly crashes a few minutes after the connection broke. | ||||||||
Steps To Reproduce | Due to how Windows internally handles sockets of programs which quit without cleaning up a socket handle, this can easily be reproduced on Windows using nc. It can be reproduced on *nix by remotely connecting (not through loop-back) with an admin client and kill -9'ing its process (random). 1) Get nc for Windows: http://joncraton.org/blog/46/netcat-for-windows [^] 2) Start the Soldat dedicated server 3) nc localhost 23073 4) Enter the admin password, hit return, execute any command. -> You will get a correct response (echo of your command). 5) Terminate nc by pressing ctrl-c (note that no 'Admin disconnected' message is displayed in the dedicated server's console) 6) Wait a few seconds, then repeat 3) and 4) -> The command will be displayed in the dedicated server's console (and will be processed by scripts), the admin client will however not receive any response. | ||||||||
Additional Information | I assume that this is caused by incorrectly handling send(), recv() or select() returning -1, or not checking the error fd after calling select(). | ||||||||
Tags | No tags attached. | ||||||||
John | |||||||||
Attached Files | |||||||||
Relationships | ||||||
|
Notes | |
(0001311) Shoozza (administrator) 2012-02-09 03:35 |
I did the steps 1..6 but I don't get this error on Windows XP. What happens: I the server never displays the 'Admin disconnected' message when I disconnect (ctrl+c'd nc). New connections receive join messages and sent messages so theres no bug for me. As I don't have access to a Windows 7 machine now I can't test it. Any other ideas on how to get this error? |
(0001312) Mr (developer) 2012-02-09 15:45 |
That is odd, I am able to reproduce it on a so far untouched and independently set up XP VM (fully patched, SP3) too. http://mologie.de/~oliver/soldat/bug154/adminbug_xp.png [^] http://mologie.de/~oliver/soldat/bug154/adminbug_w7.png [^] The issue is not related to the scripts running on the server, I have also tested it with Scripting=0 in server.ini. I also joined the server like you suggested (after taking the screenshots), the admin client did not get the join messages either. Here's the server's configuration file I used for reproducing this issue, it is basing on the default one shipped with the 1.6.2 server, only the server name, lobby registration options and port have been changed: http://mologie.de/~oliver/soldat/bug154/soldat.ini [^] |
(0001314) Mr (developer) 2012-02-11 16:07 |
I tested this with a freshly set up Soldat server (from soldatserver2.7.2_1.6.2.zip md5 70d30d7b7138c450786e7337299bc930, I only set an admin password in soldat.ini) on Windows 7 now and was able to reproduct the bug using the steps above (as shown on the screenshot on the previous note). |
(0001318) Shoozza (administrator) 2012-02-13 01:44 |
Wrong handling of exceptions was probably the reason for this error (finally -> except). |
Issue History | |||
Date Modified | Username | Field | Change |
2012-02-08 23:26 | Mr | New Issue | |
2012-02-09 03:35 | Shoozza | Note Added: 0001311 | |
2012-02-09 03:35 | Shoozza | Status | new => feedback |
2012-02-09 15:45 | Mr | Note Added: 0001312 | |
2012-02-09 15:45 | Mr | Status | feedback => new |
2012-02-11 16:07 | Mr | Note Added: 0001314 | |
2012-02-13 01:43 | Shoozza | Relationship added | duplicate of 0000124 |
2012-02-13 01:44 | Shoozza | Note Added: 0001318 | |
2012-02-13 01:44 | Shoozza | Status | new => resolved |
2012-02-13 01:44 | Shoozza | Fixed in Version | => 2.7.3 |
2012-02-13 01:44 | Shoozza | Resolution | open => fixed |
2012-02-13 01:44 | Shoozza | Assigned To | => Shoozza |
Copyright © 2000 - 2024 MantisBT Team |