Open tolland opened 4 months ago
Thought I would keep some notes on what I see (trying to increase my understanding...)
seems like the exception is being caused when initializing the new ArrayList<>(red)
from the Set<BlockPos> red
, presumably the set is being updated by another thread at the same time.
new ArrayList<>(red).stream().filter(Objects::nonNull)
.map(pos -> new BlockPos(pos.getX() - region.x(), pos.getY(),
pos.getZ() - region.z()))
.forEach(pos -> {
bufferBuilder
.vertex(pos.getX(), pos.getY() + 0.01, pos.getZ())
.color(1, 0, 0, 0.5F).next();
bufferBuilder.vertex(pos.getX() + 1, pos.getY() + 0.01,
pos.getZ() + 1).color(1, 0, 0, 0.5F).next();
bufferBuilder
.vertex(pos.getX() + 1, pos.getY() + 0.01, pos.getZ())
.color(1, 0, 0, 0.5F).next();
bufferBuilder
.vertex(pos.getX(), pos.getY() + 0.01, pos.getZ() + 1)
.color(1, 0, 0, 0.5F).next();
});
so from the stack:
java.lang.ArrayIndexOutOfBoundsException: Index 133 out of bounds for length 133
at java.base/java.util.HashMap.keysToArray(HashMap.java:950)
at java.base/java.util.HashSet.toArray(HashSet.java:368)
at java.base/java.util.ArrayList.<init>(ArrayList.java:181)
at net.wurstclient.hacks.MobSpawnEspHack$ChunkScanner.compileBuffer(MobSpawnEspHack.java:307)
at net.wurstclient.hacks.MobSpawnEspHack.onUpdate(MobSpawnEspHack.java:144)
Assuming that the problem is actually that the red
HashSet is being updated when it tries to create the ArrayList from the set, then something else must be accessing it. looks like this should ensure that scan() is complete before allowing compileBuffer to run:
List<ChunkScanner> sortedScanners = scanners.values().stream()
.filter(s -> s.doneScanning).filter(s -> !s.doneCompiling).sorted(c)
.limit(loadingSpeed.getValueI()).collect(Collectors.toList());
scanning should be complete here: https://github.com/Wurst-Imperium/Wurst7/blob/c4e22b94347374912a02ed6ccb8ee6e936e57d20/src/main/java/net/wurstclient/hacks/MobSpawnEspHack.java#L290C1-L290C24
I tried some debugging on that... https://github.com/tolland/Wurst7/blob/e0ea1e5829e19eda81de8da481fef8341784cfca/src/main/java/net/wurstclient/hacks/MobSpawnEspHack.java#L308-L312
if(!future.isDone() || !doneScanning)
{
System.out.println("Future done: " + future.isDone());
System.out.println("scanner doneScanning: " + doneScanning);
}
And I can see a bunch of logging:
[18:05:46] [ForkJoinPool.commonPool-worker-10/INFO]: [STDOUT]: Saved region successfully
[18:05:46] [pool-9-thread-2/INFO]: [STDOUT]: World save took 1294ms
[18:05:56] [Render thread/INFO]: [STDOUT]: Future done: false
[18:05:56] [Render thread/INFO]: [STDOUT]: scanner doneScanning: true
which only occurs if I am breaking lots of blocks at the time
so my guess is that onReceivedPacket is being called like so
and calling clear()
on the hashset. So at the same time the other thread for onUpdate calls compileBuffer for that scanner and that goes into the array which was cleared (or is being cleared by the previous thread)
I've been testing some possible work arounds:
1)
private final Set<BlockPos> red =
Collections.synchronizedSet(new HashSet<>());
2)
ArrayList<BlockPos> syncedRed;
synchronized(red)
{
syncedRed = new ArrayList<>(red);
}
syncedRed.stream().filter(Objects::nonNull)
.map(pos -> new BlockPos(pos.getX() - region.x(),
....
I use the same address I think there's a problem because I reset it in another class? I think it'll be solved if I merge it well with an existing instance after deep copying..
Pre-reporting checklist
Description
During mining or breaking blocks fast, the client crashes with return code 255, with a wurst exception from MobSpawnEspHack: (this happens intermittently about once a day or so) but typically when I am breaking lots of blocks such as mining with good pick, or breaking something like sugarcane.
No other breaking block hack is active. (i.e. fastbreak, excavator, nuker) however MobSpawnEsp is active.
I've been trying variations to try and reproduce the bug in a simple repeatable environment. But so far I cannot, and only experience this behaviour on a fairly busy server, with various mods running locally. (if I remove all local mods, and run against vanilla server it does not reproduce). It seems likely that it is this set of circumstances (busy server, plugins, other local mods) which trigger a fairly rare set of conditions required for the exception.
Repro steps
Wurst Client version
v7.41.2-MC1.20.4
Minecraft version
1.20.4 with Fabric Loader 0.15.7
Crash report (if applicable)