When using /stop (or the server crashes) with a player logged in, there is a high chance that a stack overflow error occurs.
This is because a move (or other packet) attempts to get queued from the network thread for processing by the server thread.
The network thread then checks if it is the main thread. It is not, so it queues it for processing.
The task handler then checks if it is not the main thread. The issue lies in that these checks are not symmetrical. The not main thread check also checks if a /stop has been issued. If it has, then it attempts to execute the queued task immediately. This causes the code to jump back to *** and eventually stack overflow.
Unfortunately I don't have a clean stack trace, but the logic checks out...
Related issues
Attachments
Comments


Reproduced on LAN world by joining a second player and quitting the host.
No error log is displayed (unless debug is enabled?), but the second players gets "Internal Exception: java.lang/StackOverflowError" when quitting.

Affects 13b, same steps.

This isn't really a problem as the stack overflow only happens on the network thread than the server thread. and since the server is stopping crashing the network thread isn't a big problem.
Can confirm in 1.18.1.
[media]