MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001248Zandronum[All Projects] Bugpublic2013-01-13 18:112018-09-30 21:36
ReporterWatermelon 
Assigned ToWatermelon 
PrioritylowSeveritytrivialReproducibilityrandom
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.0 
Target Version1.3Fixed in Version1.3 
Summary0001248: Random disconnect from players when they do not disconnect
DescriptionIf you go into the demo and demo_skiptonextmap around 4-5 times until you get to $DANNY$ vs <PRO>Torvald on the map SSL2, if you skip ahead to when Danzoa has 23 frags (demo_skiptics 5000-6000 from the beginning of the duel should move you there faster), there's a random disconnect message when Torvald does not actually disconnect.

According to the logs, they were as follows:

[13:01:13;20:36:04] Connect (v1.0): [KSHARP[S]'s IP HERE]
[13:01:13;20:36:05] client <PRO>Torvald disconnected. // Tor did not actually disconnect here
...
[13:01:13;20:36:08] $danny$ > SuperShotgun > <PRO>Torvald
...
[13:01:13;20:36:15] Connect (v1.0): [KSHARP[S]'s IP HERE]
...
[13:01:13;20:36:16] Fraglimit hit.
[13:01:13;20:36:16] $danny$ wins!
[13:01:13;20:36:16] $danny$ > SuperShotgun > <PRO>Torvald
[13:01:13;20:36:17] Ksharp[S] has connected.

It appears that when someone messes up a connect, it disconnects them but they aren't there and probably goes to the next available player or something? It shows ksharp connecting twice but there wasn't a disconnect message or anything.

Demo is here:
'http://www.speedyshare.com/388MQ/Zandronum-13.01.2013-11.12.14-doom2.wad-skulltag-data.pk3-skulltag-actors.pk3-duel32a.pk3-wbuild-plugin-v1.1b.pk3.cld [^]'

If it goes down, I'll re-upload it.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2013-01-13 18:11WatermelonNew Issue
2013-01-13 18:39Torr SamahoNote Added: 0005774
2013-01-13 18:48WatermelonNote Added: 0005775
2013-01-13 19:20Torr SamahoNote Added: 0005776
2013-01-13 21:02WatermelonNote Added: 0005779
2013-03-20 05:48WatermelonAssigned To => Watermelon
2013-03-20 05:48WatermelonStatusnew => acknowledged
2013-03-20 05:48WatermelonAssigned ToWatermelon =>
2013-03-24 13:31Torr SamahoNote Added: 0006165
2013-03-24 15:48WatermelonNote Added: 0006169
2013-03-24 15:48WatermelonNote Edited: 0006169bug_revision_view_page.php?bugnote_id=6169#r3396
2013-03-26 20:04WatermelonNote Added: 0006176
2013-03-27 16:27WatermelonNote Edited: 0006176bug_revision_view_page.php?bugnote_id=6176#r3402
2013-09-22 12:26AlienOverlordNote Added: 0007265
2013-09-22 12:27AlienOverlordNote Edited: 0007265bug_revision_view_page.php?bugnote_id=7265#r4062
2013-09-25 15:55ArcoNote Added: 0007278
2013-09-25 15:55ArcoNote Edited: 0007278bug_revision_view_page.php?bugnote_id=7278#r4075
2014-06-07 22:23WatermelonNote Added: 0008882
2014-06-07 22:23WatermelonAssigned To => Watermelon
2014-06-07 22:23WatermelonStatusacknowledged => needs review
2014-06-07 22:43DuskNote Added: 0008885
2014-06-08 00:25WatermelonNote Added: 0008893
2014-06-08 00:33WatermelonNote Added: 0008895
2014-06-08 00:33WatermelonStatusneeds review => assigned
2014-06-08 01:24DuskNote Added: 0008898
2014-06-08 09:14Torr SamahoNote Added: 0008906
2014-06-08 09:15Torr SamahoStatusassigned => needs testing
2014-06-08 09:15Torr SamahoTarget Version => 1.3
2014-07-16 00:00ArcoNote Added: 0009977
2014-07-16 00:00ArcoResolutionopen => fixed
2014-07-16 00:00ArcoFixed in Version => 1.3
2014-07-16 00:00ArcoStatusneeds testing => resolved
2018-09-30 21:36Blzut3Statusresolved => closed

Notes
(0005774)
Torr Samaho   
2013-01-13 18:39   
Is it possible that Torvald used the player slot now assigned to Ksharp before? Probably the player name of a slot is not cleared when a player disconnects.
(0005775)
Watermelon   
2013-01-13 18:48   
I checked the log file and it didn't show ksharp's IP connecting before at all for the previous 5 days (possibly even longer, just the log started 5 days ago and this is the first time he/she connected). I heard this used to happen before Zandronum back in Skulltag, so I figure it isn't a glitch with some increase in the player limit (there were only 5-6 people in the server) if that rules out any of that.

If there's anything else you want me to check I can do so.
(0005776)
Torr Samaho   
2013-01-13 19:20   
Did Torvald connect to the server before? It could be that the disconnect message simply reads the name from an empty player slot (since the connection attempt was not successful) and that Torvald was the last player who used this slot. Probably I should extend the connect / disconnect messages to mention the player slot number.
(0005779)
Watermelon   
2013-01-13 21:02   
Is there a way I can find that out through the demo? Like using 'playerinfo' or something like that?
(0006165)
Torr Samaho   
2013-03-24 13:31   
Yes, using playerinfo after a player connected will tell you which slot the player has.
(0006169)
Watermelon   
2013-03-24 15:48   
There is probably a messed up pointer or something since I've seen

Player disconnected

2 spaces in the above^

I figure it's referencing a non-existing player?
(0006176)
Watermelon   
2013-03-26 20:04   
(edited on: 2013-03-27 16:27)
Someone said they noticed it only happening in Zandro 1.1. I don't recall this happening in Skulltag. Could anything have changed?

EDIT:
What are your guys thoughts on a small fix where it will not send the disconnect message if the player is still in the game or their name/player object is null?
(0007265)
AlienOverlord   
2013-09-22 12:26   
(edited on: 2013-09-22 12:27)
"Player disconnected" — this message appears when someone disconnects while authenticating level. The player generally exists, but his nickname isn't set yet.
(0007278)
Arco   
2013-09-25 15:55   
I'm not sure if this a related issue, but sometimes the names of the clients on the server won't show up at all. It will just say "Client Disconnected."

Watermelon: I've also seen this happening albeit more frequently on v1.x, where Skulltag wasn't afflicted as much.
(0008882)
Watermelon   
2014-06-07 22:23   
This will suppress any unfinished connections from spamming the console:

'https://bitbucket.org/ChrisKOmg/zandronum/commits/3891ee18ecfe26625ee1d4a0c27c78245c3f114d [^]'
(0008885)
Dusk   
2014-06-07 22:43   
Looks like a bandage hack instead of fixing the underlying problem...

Either way I don't think V_TextContainsPrintableCharacters is necessary. You can use V_RemoveTrailingCrapFromFString to remove these characters and then check whether the string became empty.
(0008893)
Watermelon   
2014-06-08 00:25   
I'd rather fix the underlying problem but I have no idea how to track it since its completely random. KSharp was able to it quite easily somehow, but never explained how to after flooding a duel server.
(0008895)
Watermelon   
2014-06-08 00:33   
Changing to the recommended feature.

Also, since it looks like a blank string, would strlen() be valid? it seems like it converts:

printf("client %s\\c- disconnected"...)
into
"client disconnected"

Therefore, I wonder if strlen of > 0 is worth putting there instead?
(0008898)
Dusk   
2014-06-08 01:24   
I'd do something like


FString tmp ( netname_goes_here );
V_RemoveTrailingCrapFromFString( tmp );
if ( tmp.IsNotEmpty() )
{
    // netname actually contains stuff
}
(0008906)
Torr Samaho   
2014-06-08 09:14   
Looking at the initial report, blank strings are not the real problem here:
Quote

[13:01:13;20:36:04] Connect (v1.0): [KSHARP[S]'s IP HERE]
[13:01:13;20:36:05] client <PRO>Torvald disconnected. // Tor did not actually disconnect here

I hope this is a proper fix for the underlying problem.

What's going on here is the following: userinfo.netname is not cleared when a client is disconnected. That itself is not a problem, since it's properly initialized when a client finishes a connection in SERVER_ConnectNewPlayer. The consequence of this behavior is that userinfo.netname may not be used for clients that are not fully connected yet.
(0009977)
Arco   
2014-07-16 00:00   
The testing that has had a week prior can confirm that this issue has been fixed. I'll re-open this if I see otherwise.