Weird error/crash after using server_cmd("stats") and server_exec() on a clcmd
I found this weird bug while testing a plugin (that i will be release soon(tm))
First, here is an example plugin for testing the issue: PHP Code:
But, when running "test2", at client side, the message is shown, but at server, it shows an extra error msg: Code:
CPU In Out Uptime Users FPS Players Here is a message shown at the crash: Code:
SV_ReadClientMessage: too many cmds 171 sent for /00000000:000000000000:0 * Issue happens even without the console_print, but server crashes quickly with it (< 3-5 min), so i did leave it * I've already tested with 1.8.2 and a 1.9.0 build on windows [ cstrike ] (both HLDS/reHLDS), also with the same 1.9.0 build on linux with reHLDS, the issue is present on both. * I've tested some other commands, but it only seems to happen with "stats" btw, i really need the server_exec there, so deleting it's not an option. Edit: Answer |
Re: Weird error/crash after using server_cmd("stats") and server_exec() on a clcmd
A very long time ago, this happened to me every time I used server_exec() on my Linux test server. However, in the last couple years, I tested it again and it won't crash it. I tested your code and both with and without the server_exec() produce the stats output and neither crashed it.
|
Re: Weird error/crash after using server_cmd("stats") and server_exec() on a clcmd
Quote:
Also, did you test the commands as a player on the server? |
Re: Weird error/crash after using server_cmd("stats") and server_exec() on a clcmd
I didn't get any errors. I tested from the server's console (technically this shouldn't matter since server_cmd() sends the command to the server regardless of how the function gets called).
|
Re: Weird error/crash after using server_cmd("stats") and server_exec() on a clcmd
Quote:
|
Re: Weird error/crash after using server_cmd("stats") and server_exec() on a clcmd
I may be talking out of my arse, but it may be related to the fact that you are telling the engine to execute the command buffer immediately while it's processing a client command already.
Do you have to execute the command immediately? If not, try postponing it a single frame by using RequestFrame. |
Re: Weird error/crash after using server_cmd("stats") and server_exec() on a clcmd
Quote:
I've a plugin that it's like server_cmd(), but it returns the command output as a string by using condebug, made as an alternative of hooking Con_Printf with orpheu (that doesn't crash when it's second arg is not an string) the plugin it's done and i was about to post it (it was meant to be an stock, but i had to make it a plugin with api after noticing some issues) this issue was one of the delays for it, i even tested cvarlist and "maps *" and no issue with them... |
Re: Weird error/crash after using server_cmd("stats") and server_exec() on a clcmd
Can you run the server through GDB (or other debugger) and get the stack trace once it crashes? It could help us fix the issue, or at least find the cause and avoid it somehow.
|
Re: Weird error/crash after using server_cmd("stats") and server_exec() on a clcmd
I think I found the issue.
SV_ExecuteClientMessage mutates host_client and uses it in the loop while parsing/executing client messages. Once it gets to the client command message containing "test2", it will (a couple of stack frames deeper) result in your cmdTest2 command handler being called. The thing is that GetStatsString also mutates host_client, so something surely goes awry there. Possible solutions? 1. Don't execute the stats command while in a command handler, or more precisely - don't force the engine to immediately execute the command buffer (server_exec). 2. Save and restore host_client using some Orpheu magic. |
Re: Weird error/crash after using server_cmd("stats") and server_exec() on a clcmd
Quote:
so i will need to write another version of the func using callback and wrapping the server_cmd with a pre and post command |
All times are GMT -4. The time now is 05:45. |
Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.