Repository navigation
Server: fix buggy configstring transmission - #1218
Conversation
|
|
||
| static void SendConfigStringToClient( int cs, client_t *cl ) | ||
| { | ||
| char buf[ 1024 ]; // escaped characters, in a quoted context |
There was a problem hiding this comment.
Use MAX_STRING_CHARS constant?
There was a problem hiding this comment.
The immediately relevant limit here is 1022 which is hard-coded in SV_SendServerCommand. I added a comment about this. I don't believe any buffer declared with size MAX_STRING_CHARS is involved anywhere in the stack.
There was a problem hiding this comment.
Ah, I didn't exactly understand the comment, but I guess that means that 1022 + " + "?
There was a problem hiding this comment.
Well it really only needs to be 2 or 3 char longer than limit.
The bcs0, bcs1, and bcs2 commands are used to transmit an info string that has more than a certain length. The old code chopped them into pieces based on the original length rather than the escaped length and provided only a fixed amount of overhead for escape characters. Turns out the overhead wasn't enough for real-life use cases (there are a lot of backslashes due to infostring separators) and so the command to send the serverinfo configstring would sometimes overflow and be silently dropped. Fix this by chopping up the string based on the escaped length.
| // max command size for SV_SendServerCommand is 1022, leave a little overhead for the command | ||
| char *limit = buf + 990; |
There was a problem hiding this comment.
FWIW, the cs chunking code uses 1024 - 64 as the size. Does it make sense to be consistent with that?
|
This does seem to fix it, however I saw an instance of: I only saw this once, and could not reproduce it. |
I saw this on my server too but only when I played the td map. I'm unsure if it is related to this issue. |
|
Yes, also on |
|
I've seen either this or very similar message before (not on |
4 participants
The bug is described in #1215.