Failed to hook IBlockData accessor

[Bobcat00]

Multiple exceptions when using /cleanlight command.

2022-10-01 11:03:21 [INFO] Bobcat00 issued server command: /cleanlight 6
2022-10-01 11:03:21 [ERROR] [BKCommonLib] Failed to hook IBlockData accessor
java.lang.IllegalStateException: Output of getAccessor() did not change after setting accessor

Full exception log - https://pastebin.com/1QnPqj0N

BKCommonLib version 1.19.2-v2-SNAPSHOT-1392
LightCleaner version 1.19-v1
git-Paper-188 (MC: 1.19.2) You are running the latest version

Configs:

#> This is the configuration of Light Cleaner, in here you can enable or disable features as you please

# The minimum amount of memory (in MB) allowed while processing chunk lighting
# If the remaining free memory drops below this value, measures are taken to reduce it
# Memory will be Garbage Collected and all worlds will be saved to free memory
# The process will be stalled for so long free memory is below this value
minFreeMemory: 400

# Whether to skip processing chunks at the edge of the world
# Setting this to true prevents additional chunks being generated there
# This does mean the border chunks do not get cleaned
skipWorldEdge: true

# Sets whether lighting is cleaned up for newly generated chunks
# This will eliminate dark shadows during world generation
autoCleanEnabled: false

# Sets whether lighting is cleaned up when players perform WorldEdit operations
# This is primarily useful for FastAsyncWorldEdit
autoCleanWorldEditEnabled: false

# How many chunks are asynchronously loaded at the same time
# Setting this value too high may overflow the internal queues. Too low and it will idle too much.
asyncLoadConcurrency: 50

# A list of world names that have saving disabled
# Light Cleaner will not save these worlds to free up memory,
# and will not write persistent PendingLight.dat entries for these worlds
unsavedWorldNames: []

#> This is the main configuration file of BKCommonLib
#> Normally you should not have to make changes to this file
#> Unused components of the library can be disabled to improve performance
#> By default all components and features are enabled

# Whether the Map Display engine is enabled, running in the background to refresh and render maps
# When enabled, the map item tracking may impose a slight overhead
# If no plugin is using map displays, then this can be safely disabled to improve performance
enableMapDisplays: false

# Whether all item frames on the server are tracked to see if they display a map display.
# This allows for map displays to be displayed on item frames and interacted with.
# If 'enableItemFrameTiling' is also true, then this allows for multi-item frame displays.
# Tracking the existence of all item frames on the server can pose an overhead, as
# shown under the 'MapDisplayFramedMapUpdater' task. Turning this off can help performance.
# If 'enableMapDisplays' is true then player-held maps will continue working fine.
enableItemFrameDisplays: false

# Whether multiple item frames next to each other can merge to show one large display
# This allows Map Displays to be displayed on multiple item frames at a larger resolution
# The tiling detection logic poses some overhead on the server, and if unused, can be disabled
enableItemFrameTiling: false

# Whether to teleport players to their supposed seat while they hold the sneak button
# This is used on Minecraft 1.16 and later to make sure players stay near their seat,
# when exiting the seat was cancelled.
teleportPlayersToSeat: false

# Whether to force saving to be done synchronously, rather than asynchronously
# If the Asynchronous File I/O in the JVM has a glitch in it, it might cause very large
# corrupt (.yml) files to be generated. On server restart this can cause a loss of data.
# Synchronous saving (such as YAML) may hurt server performance for large files,
# but will prevent these issues from happening.
forceSynchronousSaving: false

# Whether to instrument additional Timings for some of the core BKCommonLib components
# These timings might be useful to identify performance problems, or their causes
# They may cause a slight performance hit, so leave this option disabled unless you need them
debugTimings: false

# Whether to disable using brigadier for all plugins that use BKCL's cloud command framework
# This might fix problems that occur because of bugs in brigadier, or cloud's handler of it
cloudDisableBrigadier: false

# Whether to load and initialize ALL template classes when BKCommonLib first loads up.
# This reveals any at-runtime server incompatibility errors early on and eliminates any
# at-runtime lazy initialization lag. It does cause a lot of classes to be loaded into the
# JVM that may never get used, which wastes memory. Only enable this for debugging reasons!
preloadTemplateClasses: false

[bergerkiller]

Interesting, I got the same. Thankfully it has a fallback system so this error has no real impact, other than a slightly reduced performance as it falls back to a hashmap. I'll try to fix it.

[bergerkiller]

Well thats silly. Its because im modifying a final field which is non-volatile, so very randomly the field doesnt change right away and the verification check fails. I'll change it a bit so it does this check only one time in a controlled manner.

[bergerkiller]

This should fix it permanently. https://ci.mg-dev.eu/job/BKCommonLib/1393/

[Bobcat00]

Tested fine. Thanks!