FastAsyncWorldEdit

FastAsyncWorldEdit

152k Downloads

NPE with clipboard patterns/brushes when player clipboard changed after pattern/brush creation

KalebDev1 opened this issue ยท 6 comments

commented

Server Implementation

Paper

Server Version

1.18.2

Describe the bug

When you select an area, perform //copy and go to assign it to a brush (eg. /br clipboard -ao) it will work perfectly. However, let's say that you messed up the point where you copied from and went back to perform //copy once more. The blocks copy but when you go to use the brush it will not work and will spam console with hundreds of different errors repeating it and then tens of thousands of NullPointerExceptions over period of ~ 5 seconds.

To Reproduce

//pos1 & //pos2
//copy
//gmask 0
/br clipboard -ao
//copy
(Then use the brush again.)

Expected behaviour

I expected the copy and work the brush properly.

Screenshots / Videos

https://youtu.be/SR4rlzdeo4w

Error log (if applicable)

https://gist.github.com/KalebDev1/604562582992900f1e83af55ce925f05

Fawe Debugpaste

https://athion.net/ISPaster/paste/view/5b8f76a1f98e44e28166decf6a91efa9

Fawe Version

FastAsyncWorldEdit-Bukkit-2.4.1-SNAPSHOT-239

Checklist

Anything else?

No response

commented

@KalebDev1 Could you please clarify the issue from these two options:

  1. Setting the gmask to 0 for a clipboard brush causes errors.
  2. Changing the clipboard after setting a clipboard brush (//copy, /br clipboard, //copy, use brush) causes errors.

Your steps for replication seem to either be misformatted (causing some confusion), or your description of the problem doesn't quite match your steps for replication.

Thanks!

If you're confused by the steps I provided in the formatting I have provided a video of the method I used to replicate the error.

commented

@KalebDev1 If you're confused by the steps I provided in the formatting I have provided a video of the method I used to replicate the error.

Looks like your YouTube account was terminated, at least that's what it shows on my end lol! It's fine though, it seems we have a solid understanding of the issue.

commented

@KalebDev1 Could you please clarify the issue from these two options:

  1. Setting the gmask to 0 for a clipboard brush causes errors.
  2. Changing the clipboard after setting a clipboard brush (//copy, /br clipboard, //copy, use brush) causes errors.

Your steps for replication seem to either be misformatted (causing some confusion), or your description of the problem doesn't quite match your steps for replication.

Thanks!

commented

@IronApollo

I've got this issue and am implementing a full fix and signifigant improvements to the file-backed clipboard manager.

The issue is that the file-backed clipboard does all its operations directly on a direct buffer to the file, and this direct buffer (along with the file) are closed and inaccessible when going forwards then backwards in history under the circumstances created by this issue. (additionally, I am investigating the possibly of other bugs causing failure to properly clean up history state when pushed onto the history stack (hence preventing the proper closing of the file) which seems to a secondary bug causing this bug to not normally present itself.)

commented

The issue in question is nothing to do with the clipboard being closed by any history, and has nothing to do with a players' history, it's also actually nothing to do with //gmask 0. When the player's clipboard is reset/remade, the old clipboard should absolutely no longer be accessible if clipboard-on-disk is used. Clipboard files are uncompressed (at 2 bytes per block) as random R/W access to a compressed file is not ideal, and is not great to implement, therefore, the same "file" is used each time a player creates a clipboard to prevent numerous large files being created (a 500x256x500 clipboard is 128MB).

The solution to the problem is therefore either that the clipboard brushes/masks etc. need to be refactored to use a ClipboardHolder (where the clipboard can be replaced without causing an issue), or the error handled better and the issue explained to the player (that they cannot clear/replace their clipboard whilst it's being used).

commented

Just going to leave the error I'm getting here in case it helps solve the issue: https://pastebin.com/puKGnvkk