Bug 3418 - netchan queue is not properly initialized
Status: RESOLVED FIXED
Alias: None
Product: ioquake3
Classification: Unclassified
Component: Misc
Version: GIT MASTER
Hardware: All All
: P3 minor
Assignee: Zachary J. Slater
QA Contact: ioquake3 bugzilla mailing list
URL:
Depends on:
Blocks:
 
Reported: 2007-11-11 17:18 EST by Tim Angus
Modified: 2009-09-14 19:13:08 EDT
1 user (show)

See Also:



Description Tim Angus 2007-11-11 17:18:09 EST
OK, i think i found a solution after exploring what it does... Problem
is, checking if  "netchan queue has been properly initialized" should
not be performed on zombies which all recently disconnected clients
are, until engine sets them free in next few seconds after disconnect.

Also there is simpler way to reproduce this bug -- just add 20+ bots
and then issue 'kick allbots' or 'kick all' from the server console or
rcon. Server should crash with message:

"ERROR: netchan queue is not properly initialized in
SV_Netchan_TransmitNextFragment"
..."Server Shutdown (Server crashed: netchan queue is not properly
initialized in SV_Netchan_TransmitNextFragment"

Original code:
        // make sure the netchan queue has been properly initialized
(you never know)
        if (!client->netchan_end_queue) {
            Com_Error(ERR_DROP, "netchan queue is not properly
initialized in SV_Netchan_TransmitNextFragment\n");
        }

Fixed:
        // make sure the netchan queue has been properly initialized
(you never know)
        // DD - skip just disconnected and zombies (CS_ZOMBIE)
        if (!client->netchan_end_queue && client->state != CS_ZOMBIE) {
            Com_Error(ERR_DROP, "netchan queue is not properly
initialized in SV_Netchan_TransmitNextFragment\n");
        }

Credit goes to: DD

Note: you may use 'client->state >= CS_CONNECTED' instead of
'client->state != CS_ZOMBIE', if you want to skip CS_FREE clients too.
I used != CS_ZOMBIE because recently kicked players get zombie state
for a few seconds and error occurred after kicking a lot of players at
once.

I tested it few times with 20-24 bots and it kicked them all without an error.


On 11/7/07, dyn <dynborg@vogonhq.com> wrote:
> This is present in original q3 also, not only in ioq3 and apparently
> it's not fixed yet.
>
> It may happen when you add multiple bots and then issue 'kick allbots'
> command. I was only player left on server. After few tests it seems to
> occur more likely if you add 15-20 bots, issue /nextmap (or  load next
> map) and then add 1-2 more bots and then 'kick all'.
>
> There was some discussion about it, but all solutions mentioned are
> non-working and not very logical either:
> http://www.quake3world.com/forum/viewtopic.php?f=16&t=9220
Comment 1 ensiform 2007-11-15 19:25:07 EST
torhu in that link said:

> It seems that the bug is fixed now.

> I just commented out this line in StopFollowing():
> ent->r.svFlags &= ~SVF_BOT;

> But I don't know why that helps. I hope it doesn't cause trouble elsewhere, but nothing so far. This would mean that this function sometimes is called for bots, I guess. It happens a bit too rare to bother testing for that right now.

However, would it not be smarter to just force the botflag off in SpectatorClientEndFrame if they weren't a bot (in the first place, because technically StopFollowing clears bot even if they were a bot spectating [which could happen if you were controlling them]).
Comment 2 Ryan C. Gordon 2009-09-14 19:13:08 EDT
Fixed in svn revision #1596.

--ryan.