Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Admin port: No synchronisation in NetworkAdminConsole which may be called from any thread #9388

Closed
JGRennison opened this issue Jun 19, 2021 · 1 comment
Milestone

Comments

@JGRennison
Copy link
Contributor

@JGRennison JGRennison commented Jun 19, 2021

Version of OpenTTD

master

Expected result

No thread safety issues.

Actual result

NetworkAdminConsole may be called at any time from any thread via the Debug macro.
This iterates ServerNetworkAdminSocketHandler instances and calls ServerNetworkAdminSocketHandler::SendConsole as required without performing any synchronisation.
Iterating ServerNetworkAdminSocketHandler whilst it is being modified could theoretically result in unwanted behaviour.
Concurrent calls to Packet::AddToQueue, or concurrent calls to Packet::AddToQueue and Packet::PopFromQueue, could theoretically result in a malformed packet queue.

I noticed this issue because I received a crash report where the above issue was triggered by debug messages logged from the UDP advertisement thread.

JGRennison added a commit to JGRennison/OpenTTD-patches that referenced this issue Jun 20, 2021
@rubidium42
Copy link
Contributor

@rubidium42 rubidium42 commented Jul 23, 2021

I think the issue is bigger than what you have fixed in your patch. Under the assumption that _settings_client.gui.developer >= 2 IConsolePrint gets called which might also call NetworkServerSendRcon and NetworkServerSendAdminRcon.

Similarly send(_debug_socket... in DebugPrint might be prone to the same issue, although that would be more "unintended" behaviour: 'send should not be called on the same stream-oriented socket concurrently from different threads, because some Winsock providers may split a large send request into multiple transmissions, and this may lead to unintended data interleaving from multiple concurrent send requests on the same stream-oriented socket' (winsock2 send() documentation). That might be solved easily with a guard in the actual function.

I am wondering what the effect would be of just queueing those debug messages after fputs, and then pushing them to the admins and in-game console from the "safe" thread. In really spammy debug sessions that might create quite a queue in-memory, so we ought to employ a similar check to whether to queue you have added.
That would also have the added benefit of not accidentally passing debug prints as replies to RCons.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants