MC-142590StackOverflowError when using /stop with player logged in
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...
Linked Issues
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
![[Mod] md_5](../../../data/avatars/users/10122.svg){kind=small}
ImportantCreated Issue:
Small chance of StackOverflowError when using /stop with player logged in
When using /stop with a player logged in, there is a small 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 since its hard to reproduce, but the logic checks out...
Small chance ofStackOverflowError when using /stop with player logged in
When using /stop with a player logged in, there is a
smallchance 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
since its hard to reproduce, but the logic checks out...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...
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
relates to
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
Stack overflow is probably just instance of MC-142590. Not really relevant to discussion.
`crash-2019-05-09_02.14.23-server` is caused by server spending too much time on single tick (it seem to be generating chunks accessed by zombie AI), which is probably end of long chain of delays, maybe caused by server in spending too much time on garbage collection.
Also, in heapdump average memory taken by single chunk is about 20MB - game is storing much more that just blocks. Number of loaded chunks can be increased by lag, since loading and unloading operations are not immediate.
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
Hello,
As you said, this does not seem to be recoverable lag, so it will be kept open.
However, note that the StackOverflowError you saw is likely caused by MC-142590.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
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. MC-142590.png