Server Implementation

Paper

Server Version

1.19.2

Describe the bug

FAWE crashes JVM on huge schematic pasting if player-executor leave the server before paste completion.

To Reproduce

1. Create a huge schematic with /schematic save (>=2.5M blocks in total e.g.).
2. Load the created schematic and paste it.
3. Leave the server immediately (before paste process completion).
4. See JVM crash log in the server console.

Expected behaviour

FAWE should not crash the JVM when performing large operations.

Screenshots / Videos

No response

Error log (if applicable)

https://paste.gg/p/anonymous/6a1b634de23342a889b3b7aa30791c00

Fawe Debugpaste

https://athion.net/ISPaster/paste/view/7d92b9560c374e658a9b193b5a313467

Fawe Version

2.4.8-SNAPSHOT-291

Checklist

• I have included a Fawe debugpaste.
• I am using the newest build from https://ci.athion.net/job/FastAsyncWorldEdit/ and the issue still persists.

Anything else?

No response

Same issue

I'm not able to replicate the issue, based on the information provided.
Leaving the server cancels the paste event fine for me.
The server runs on https://github.com/itzg/docker-minecraft-server with Paper 1.19.2 build 199 and FAWE 2.4.8 build 291 on OpenJDK 19 build 36.

You ticked Paper as platform, but you are using Purpur. Only the platforms you can tick are supported. If you can replicate the issue on my environment, please open a new issue.

I can't reproduce that issue exactly, but rather have a few other errors to pass along: https://h.pschwang.eu/sicizeteci.md

You didn't leave the server immediately after running the //paste command. Maybe this played a role and the bug didn't appear. I can safely assume that this isn't a local problem since this bug was reproduced on one of the other servers.

I can't reproduce that issue exactly, but rather have a few other errors to pass along: h.pschwang.eu/sicizeteci.md

You didn't leave the server immediately after running the //paste command. Maybe this played a role and the bug didn't appear. I can safely assume that this isn't a local problem since this bug was reproduced on one of the other servers.

In that particular snippet, yes. Tried it before with pasting and leaving immediately - nothing happend, that's why I re-executed the command and the named errors were thrown.

@NotMyFault
Thank you for quick response.

Java 17 + Paper 1.19.2 (Build 199) + FAWE 2.4.8-291 => Issue still persists
Java 18 + Paper 1.19.2 (Build 199) + FAWE 2.4.8-291 => Issue still persists
Java 19 + Paper 1.19.2 (Build 199) + FAWE 2.4.8-291 => Issue still persists (your environment)

It seems I should provide additional info for you.
All tests were performed on clean generated server instances on Paper.
Servers also run in Docker containers managed by Pterodactyl. Docker images used in tests (if it makes sense):
— Java 17: ghcr.io/pterodactyl/yolks:java_17 (https://github.com/pterodactyl/yolks/tree/master/java/17)
— Java 18: ghcr.io/pterodactyl/yolks:java_18 (https://github.com/pterodactyl/yolks/tree/master/java/18)
— Java 19: ghcr.io/parkervcp/yolks:java_19 (https://github.com/parkervcp/yolks/tree/master/java/19)

You can find schematic file for tests here. Also I can provide a demo video if required.

Using clipboard direclty (//copy then //paste) doesn't lead to issue btw.
I suppose FAWE actually cancels huge operation process on executor leave as log says, but not cancels schematics pasting for some reason.

[22:01:09 WARN]: com.fastasyncworldedit.core.internal.exception.FaweException: Manual cancellation
[22:01:09 WARN]: [com.fastasyncworldedit.core.FaweCache] FaweException: Manual cancellation
[22:01:09 WARN]: [com.fastasyncworldedit.core.queue.implementation.SingleThreadQueueExtent]

I can't reproduce that issue exactly, but rather have a few other errors to pass along: https://h.pschwang.eu/sicizeteci.md

This looks like a race condition between closing the clipboard (and especially invoking the cleaner for the underlying DirectByteBuffer