FS#1650 - assertion during re-connect when server restarted

Attached to Project: OpenTTD
Opened by Ingo von Borstel (planetmaker) - Sunday, 13 January 2008, 17:24 GMT
Last edited by Remko Bijker (Rubidium) - Tuesday, 15 January 2008, 13:50 GMT
Type Bug
Category Core
Status Closed
Assigned To Zdeněk Sojka (SmatZ)
Operating System Windows
Severity Medium
Priority Normal
Reported Version 0.6.0-beta1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


On January 12 my client (beta2) crashed to the desktop during re-connect with an assertion failure when dihedral's server 3 restared as scheduled. A core dump is also available, if required.
This task depends upon

Closed by  Zdeněk Sojka (SmatZ)
Saturday, 15 March 2008, 00:31 GMT
Reason for closing:  Fixed
Additional comments about closing:  In r12367
Comment by Loïc GUILLOUX (glx) - Sunday, 13 January 2008, 17:28 GMT
Please attach crash.dmp.
Comment by Ingo von Borstel (planetmaker) - Monday, 14 January 2008, 19:06 GMT
crash.dmp related to it.
(application/octet-stream)    crash.dmp (1.31 MiB)
Comment by Loïc GUILLOUX (glx) - Monday, 14 January 2008, 23:03 GMT
It is a forced crash after displaying "Trying to execute a packet in the past!" in console.
Comment by Remko Bijker (Rubidium) - Tuesday, 15 January 2008, 13:49 GMT
Is this in *any* way reproduceable because I cannot found anything 'wrong' with the code.

The client would've been disconnected from the server while downloading because all connections are destroyed. Then the client would reconnect, but during the reconnect the queue of commands would be emptied. Furthermore the client can only join once the frame counter and friends are reset.

That's basically making none of the join scenarios a way to reproduce this issue.
Comment by Zdeněk Sojka (SmatZ) - Saturday, 02 February 2008, 20:23 GMT
Maybe there is a packet in the packet queue. When the connection is lost, the packects in the queue are not erased.
Then, when starting NetworkGameLoop again, it loads the packet from previous game. It has higher packet number, so the game asserts.

Only theory, I haven't looked into the code.
Comment by Ingo von Borstel (planetmaker) - Thursday, 07 February 2008, 17:53 GMT
A few days ago (sorry, don't have crash report there), a probably similar (same?) thing happened. OTTD exited with a message along the lines "old data packet received". Previously I had tried several times to connect to that server unsucessfully. The reason for the unsuccessful login attempts propably are a combination of slow(er) hardware and monstrously big and train-overloaded game (was on ottdcoop with ~1000 trains with 1024^2 map).
IMO this kinda supports SmatZ view.