Kademlia
- Kademlia
- kademlia
- Europe/Stockholm
- Yes
- No
MC-80298![[Mojang] Georgii Gavrichev](../../../data/avatars/users/22428.png){kind=small}
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
MC-100341MC-102236MC-169102
The MC-Client will ignore specific packages if there is not a minimum amount of time between them (i suspect a client-side game tick and two packet queues depending on destroy or create events. Rather than using only one queue to keep the packetsequence in order).
Unfortunately i dont know how to reproduce this problem without altering the server code. In theory it works by:
- Case 1 (Problem occuring) :
1. Having an entity ( ID = 1)
2. Sending a destroy-packet ( ID = 1)
3. Sending a spawn-packet (ID = 1)
The spawn-packet will be ignored and the client wont track the entity with ID = 1 again.
(This might happen with network instability or high-pings and routing-changes)
- Case 2 (No Problem occuring)
This does not happen if:
1. Having an entity ( ID = 1)
2. Sending a destroy-packet ( ID = 1)
3. Wait some milliseconds on the server-process
3. Sending a spawn-packet (ID = 1)Code Example for # Case 1:
Packet destroy = new PacketPlayOutEntityDestroy(entityId);
player.sendPacket(destroy);
Packet packet = new PacketPlayOutSpawnEntityLiving(entityLiving);
player.sendPacket(packet);Code Example for # Case 2:
Packet destroy = new PacketPlayOutEntityDestroy(entityId);
player.sendPacket(destroy);
Thread.sleep(50);
Packet packet = new PacketPlayOutSpawnEntityLiving(entityLiving);
player.sendPacket(packet);This Bug can result in some common things like:
- Items that are impossible to pick up
- Invisible entities/players for some players
- Visible entities a player is not able to interact with
This might be considered a duplicate of
MC-65040but as this ticket describes a very specific way to create this condition it may be either another problem or a sub-problem becauseMC-65040might be caused by different things.The MC-Client will ignore specific packages if there is not a minimum amount of time between them (i suspect a client-side game tick and two packet queues depending on destroy or create events. Rather than using only one queue to keep the packetsequence in order).
Unfortunately i dont know how to reproduce this problem without altering the server code. In theory it works by:
Case 1 (Problem occuring) :
1. Having an entity ( ID = 1)
2. Sending a destroy-packet ( ID = 1)
3. Sending a spawn-packet (ID = 1)
The spawn-packet will be ignored and the client wont track the entity with ID = 1 again.
(This might happen with network instability or high-pings and routing-changes)Case 2 (No Problem occuring)
This does not happen if:
1. Having an entity ( ID = 1)
2. Sending a destroy-packet ( ID = 1)
3. Wait some milliseconds on the server-process
3. Sending a spawn-packet (ID = 1)Code Example for # Case 1:
Packet destroy = new PacketPlayOutEntityDestroy(entityId);
player.sendPacket(destroy);
Packet packet = new PacketPlayOutSpawnEntityLiving(entityLiving);
player.sendPacket(packet);Code Example for # Case 2:
Packet destroy = new PacketPlayOutEntityDestroy(entityId);
player.sendPacket(destroy);
Thread.sleep(50);
Packet packet = new PacketPlayOutSpawnEntityLiving(entityLiving);
player.sendPacket(packet);This Bug can result in some common things like:
- Items that are impossible to pick up
- Invisible entities/players for some players
- Visible entities a player is not able to interact with
This might be considered a duplicate of
MC-65040but as this ticket describes a very specific way to create this condition it may be either another problem or a sub-problem becauseMC-65040might be caused by different things.
The MC-Client will ignore specific packages if there is not a minimum amount of time between them (i suspect a client-side game tick and two packet queues depending on destroy or create events. Rather than using only one queue to keep the packetsequence in order).
Unfortunately i dont know how to reproduce this problem without altering the server code. In theory it works by:
Case 1 (Problem occuring) :
1. Having an entity ( ID = 1)
2. Sending a destroy-packet ( ID = 1)
3. Sending a spawn-packet (ID = 1)
The spawn-packet will be ignored and the client wont track the entity with ID = 1 again.
(This might happen with network instability or high-pings and routing-changes)Case 2 (No Problem occuring)
This does not happen if:
1. Having an entity ( ID = 1)
2. Sending a destroy-packet ( ID = 1)
3. Wait some milliseconds on the server-process
3. Sending a spawn-packet (ID = 1)Code Example for # Case 1:
Packet destroy = new PacketPlayOutEntityDestroy(entityId);
player.sendPacket(destroy);
Packet packet = new PacketPlayOutSpawnEntityLiving(entityLiving);
player.sendPacket(packet);Code Example for # Case 2:
Packet destroy = new PacketPlayOutEntityDestroy(entityId);
player.sendPacket(destroy);
Thread.sleep(50);
Packet packet = new PacketPlayOutSpawnEntityLiving(entityLiving);
player.sendPacket(packet);Workaround
As this problem is dependent on the entity-ID it is possible to trick the client by changing the entity-ID
1. Having an entity ( ID = 1)
2. Sending a destroy-packet ( ID = 1)
3. Change the ID of the entity fom 1 to 2
4. Sending a spawn-packet (ID = 2)This Bug can result in some common things like:
- Items that are impossible to pick up
- Invisible entities/players for some players
- Visible entities a player is not able to interact with
This might be considered a duplicate of
MC-65040but as this ticket describes a very specific way to create this condition it may be either another problem or a sub-problem becauseMC-65040might be caused by different things.
The MC-Client will ignore specific packages if there is not a minimum amount of time between them (i suspect a client-side game tick and two packet queues depending on destroy or create events. Rather than using only one queue to keep the packetsequence in order).
Unfortunately i dont know how to reproduce this problem without altering the server code. In theory it works by:
Case 1 (Problem occuring) :
1. Having an entity ( ID = 1)
2. Sending a destroy-packet ( ID = 1)
3. Sending a spawn-packet (ID = 1)
The spawn-packet will be ignored and the client wont track the entity with ID = 1 again.
(This might happen with network instability or high-pings and routing-changes)Case 2 (No Problem occuring)
This does not happen if:
1. Having an entity ( ID = 1)
2. Sending a destroy-packet ( ID = 1)
3. Wait some milliseconds on the server-process
3. Sending a spawn-packet (ID = 1)Code Example for # Case 1:
Packet destroy = new PacketPlayOutEntityDestroy(entityId);
player.sendPacket(destroy);
Packet packet = new PacketPlayOutSpawnEntityLiving(entityLiving);
player.sendPacket(packet);Code Example for # Case 2:
Packet destroy = new PacketPlayOutEntityDestroy(entityId);
player.sendPacket(destroy);
Thread.sleep(50);
Packet packet = new PacketPlayOutSpawnEntityLiving(entityLiving);
player.sendPacket(packet);Workaround
As this problem is dependent on the entity-ID it is possible to trick the client by changing the entity-ID
1. Having an entity ( ID = 1)
2. Sending a destroy-packet ( ID = 1)
3. Change the ID of the entity fom 1 to 2
4. Sending a spawn-packet (ID = 2)
This scenario will not present the bug.This Bug can result in some common things like:
- Items that are impossible to pick up
- Invisible entities/players for some players
- Visible entities a player is not able to interact with
This might be considered a duplicate of
MC-65040but as this ticket describes a very specific way to create this condition it may be either another problem or a sub-problem becauseMC-65040might be caused by different things.
Map-Changes (Map Items as well as Maps inside of ItemFrames) ignore World-Changes after changing the world.
Reproduce
Tested with a Client<>Server setup on localhost as well as a dedicated server
1. Create a Map and let it render / place it into an itemframe
2. Change the world to the end
3. Change the world to the default world
4. Manipulate the surrounding. The changes will not be represented by the map
(5. Reconnect to the Server, the map will now work properly again)
(6. Retry step 2 to 4 to recreate the problem)Additional Information:
I stumbled upon this client-bug when developing some new plugins for bukkit and was able to reproduce them in vanilla. I´d appreciate if this gets fixed as it would allow things like this without any client-modifications:
http://i.imgur.com/eDebtiv.png
http://gfycat.com/MediocreGenerousCamel
http://www.reddit.com/r/Minecraft/comments/30jqn2/it_just_doesnt_feel_the_same/Map-Changes (Map Items as well as Maps inside of ItemFrames) ignore World-Changes after changing the world. Only the client ignores the changes. The server has valid data and reports it to all players. Players who never changed the world in the current session accept those updates. Players that did change the world do not accept the updates.
Reproduce
Tested with a Client<>Server setup on localhost as well as a dedicated server
1. Create a Map and let it render / place it into an itemframe
2. Change the world to the end
3. Change the world to the default world
4. Manipulate the surrounding. The changes will not be represented by the map
(5. Reconnect to the Server, the map will now work properly again)
(6. Retry step 2 to 4 to recreate the problem)Additional Information:
I stumbled upon this client-bug when developing some new plugins for bukkit and was able to reproduce them in vanilla. I´d appreciate if this gets fixed as it would allow things like this without any client-modifications:
http://i.imgur.com/eDebtiv.png
http://gfycat.com/MediocreGenerousCamel
http://www.reddit.com/r/Minecraft/comments/30jqn2/it_just_doesnt_feel_the_same/
Maps will be kept in memory even after disconnecting from a server.
Proof: https://youtu.be/2vcMEGn4IgI ( 1Min 32 Sec )
The Video shows multiple reconnects to a Server resulting in a OutOfMemoryError with Vanilla 1.8.6The only possible workaround is to restart the Minecraft-Client.
This is related to
MC-46345(MC-80297) and might be caused by the same faulty code - but the bug in itself is different.
Maps will be kept in memory even after disconnecting from a server.
Proof: https://youtu.be/2vcMEGn4IgI ( 1Min 32 Sec )
The Video shows multiple reconnects to a Server resulting in a OutOfMemoryError with Vanilla 1.8.6The only possible workaround is to restart the Minecraft-Client.
This is related to
MC-46345(MC-80297) and might be caused by the same faulty code - but the bug in itself is different.Additionally the Video shows that Map-Color Bug mentioned in
MC-73040and inMC-73427. From a programmers point of view
closing the topics seems a bit odd, as the changes directly go against the default behavior of Java Color-Codes.
Maps will be kept in memory even after disconnecting from a server.
Proof: https://youtu.be/2vcMEGn4IgI ( 1Min 32 Sec )
The Video shows multiple reconnects to a Server resulting in a OutOfMemoryError with Vanilla 1.8.6The only possible workaround is to restart the Minecraft-Client.
This is related to
MC-46345(MC-80297) and might be caused by the same faulty code - but the bug in itself is different.Additionally the Video shows that Map-Color Bug mentioned in
MC-73040and inMC-73427. From a programmers point of view
closing the topics seems a bit odd, as the changes directly go against the default behavior of Java Color-Codes.
Maps will be kept in memory even after disconnecting from a server.
Proof: https://youtu.be/2vcMEGn4IgI ( 1Min 32 Sec )
The Video shows multiple reconnects to a Server resulting in a OutOfMemoryError with Vanilla 1.8.6The only possible workaround is to restart the Minecraft-Client.
This is related to
MC-46345(MC-80297) and might be caused by the same faulty code - but the bug in itself is different.Additionally the Video shows that Map-Color Bug mentioned in
MC-73040and inMC-73427. From a programmers point of view
closing the topics seems a bit odd, as the changes directly go against the default behavior of Java Color-Codes.
Maps will be kept in memory even after disconnecting from a server.
Proof: https://youtu.be/2vcMEGn4IgI ( 1Min 32 Sec )
The Video shows multiple reconnects to a Server resulting in a OutOfMemoryError with Vanilla 1.8.6The only possible workaround is to restart the Minecraft-Client.
This is related to
MC-46345(MC-80297) and might be caused by the same faulty code - but the bug in itself is different.Update
This issue is not fixed in 1.9.2.
Proof: https://www.youtube.com/watch?v=biQF9qu2ww8
MC-46345only refers to the maps no longer updating.
This report refers to the memory never being cleared and ultimately causing a OutOfMemoryError.
Windows
8Windows 10
The Code in ChunkSelection.java that reports if a specific part of a chunk needs to be delivered to a client or not is faulty:
I'm not sure what the Class is named in the obfuscation. In the partially deobfuscated code its ChunkSelection.java and the Methodname ist "public boolean a()".
Im guessing its "public boolean hasBlockData()" in the original code
ChunkSelection.javapublic boolean a(){ return this.nonEmptyBlockCount == 0; }This method is called when a Chunk is placed in the OutgoingQueue to a Client. It checks if a ChunkSelection should be delivered or not.
The code does not consider the fact that - even if there is no block in a chunkselection - there may still be light-information for that selection.This results in light-Bugs on the client side if a Chunk hast light-information in a chunkselection that does not contain any blocks.
- World Seed for reproduction: -9208998853395889608 ( 1.8.x WorldGenerator. Specifically 1.8.6 singleplayer in the video)
This Video presents the bug: https://www.youtube.com/watch?v=sfikoyETsJU ( 63 Seconds )Video Content:
- Connecting to a Singleplayer World (same in Multiplayer)
- Two Chunks have obvious light-Information missing
- Teleporting does not fix the problem
- Placing a Block inside that specific chunkselection - thus working around the bug - does not fix the bug initially as the information only get updated on ChunkSending.
- Teleporting post the workaround does fix the bug
- Removing the Block - recreating the empty chunkselection and recreating the bug does work post teleport
- F3 Shows we are exactly at the edge of a chunkSelection (63/64)
- The client-side light-updates in the area around a player does only fix the problem temporarily
This can be fixed by changing the code:
ChunkSelection.javapublic boolean a(){ // return this.nonEmptyBlockCount == 0; return false; //kade fix, bukkit/mc reports wrongly if a part of a chunk is empty or not. }Performance and Gameplay implications of this bugfix
- Performance
The performance impact is negligible. The problem occurs in <5% of chunks. Specifically: It occurs in every Chunk that has Blocks at the top of one ChunkSelection and light-information in the one above that but no blocks.
- Bandwidth
The Bandwidth increases a small amount for the <5% Chunks. But as all that is being sent is the light-map we are talking about a compressed data of only some bytes more.
- Gameplay
There are absolutely no side-effects of this fix. I have been running this code-change on my servers for at least 1 1/2 years now (concurrent playercount > 300).Conclusion
In essence the Idea behind the "nonEmptyBlockCount == 0"-Check is good. But its neglecting the fact that there might be light-information present. As ChunkSelections without any lightinformation are null anyways there is no need for that check.
Hey,
blocktypes in Minecraft are marked as ticking if they can be activated by the random growth algorithm.
Examples would be crops, grass or fire.Several other blocks have no ticking-functionality but are still marked as ticking. An example would be the Cake or the Button-Blocks.
This causes problems with the growth-algorithm and chunk-indexing on chunk-loads. Each time a chunk is loaded it will count all ticking blocks. If the count is == 0 the specific chunk has no tickable blocks and will not need to be randomly checked every tick and try to grow something.
Unfortunately this benefit never really occurs if so many blocks are marked as ticking when in fact they cannot tick.
Maybe some additional information as I have some optimizations running for some time now:
- A large amount of ChunkSections will always need to tick as they contain growable blocks like grass so the optimizations here are limited
- Currently only the ChunkSections contain a counter that indicates if it needs to be ticked, a Chunk itself could contain this too and reduce the lookups at runtime
- Redstoneores tick just to de-light them after being touched by a player. Disabling this or changing it to a temporary client-side animation drastically reduces the random lookups in lower parts of the world.
- Sand an Gravel are marked as ticking but don't do anything (it was probably intended to randomly tick them so 'flying' sand would fall down at some point).
- Removing Sand, Gravel,Lava,Water and RedsteoneOre from the tickable-blocks will nearly eliminate any need of ticking lower chunksections
2013-03-04 20:39:03 [SERVER] [INFO] Preparing start region for level 0 loading single player 2013-03-04 20:39:04 [SERVER] [INFO] Kumasasa[/127.0.0.1:0] logged in with entity id 164 at (181.97781539067591, 71.5, -108.6714197356012) 2013-03-04 20:39:58 [SERVER] [INFO] Saving and pausing game... 2013-03-04 20:39:58 [SERVER] [INFO] Saving chunks for level 'Test-Welt'/Overworld 2013-03-04 20:39:58 [SERVER] [INFO] Saving chunks for level 'Test-Welt'/Nether 2013-03-04 20:39:58 [SERVER] [INFO] Saving chunks for level 'Test-Welt'/The End 2013-03-04 20:39:59 [SERVER] [INFO] Stopping server 2013-03-04 20:39:59 [SERVER] [INFO] Saving players java.io.IOException: Stream Closed at java.io.RandomAccessFile.write(Native Method) at java.io.RandomAccessFile.writeInt(Unknown Source) at aca.a(SourceFile:307) at aca.a(SourceFile:249) at acb.close(SourceFile:230) at java.util.zip.DeflaterOutputStream.close(Unknown Source) at java.io.FilterOutputStream.close(Unknown Source) at acd.a(SourceFile:137) at acd.c(SourceFile:125) at akp.b(SourceFile:29) at akp.run(SourceFile:22) at java.lang.Thread.run(Unknown Source) 2013-03-04 20:39:59 [SERVER] [INFO] Saving worlds 2013-03-04 20:39:59 [SERVER] [INFO] Saving chunks for level 'Test-Welt'/Overworld 2013-03-04 20:39:59 [SERVER] [INFO] Saving chunks for level 'Test-Welt'/Nether 2013-03-04 20:39:59 [SERVER] [INFO] Saving chunks for level 'Test-Welt'/The End 2013-03-04 20:40:00 [CLIENT] [INFO] Stopping!
Hello, this report fixes a saving-bug that has been in minecraft for years.
What is the problem? What happens?
Sometimes Chunks in the world wont be saved or overwritten by a newly generated chunk. The information of these chunks will be lost. This even happens partially without any error messages.
When does this happen?
Very rarely. This is mostly a problem of Servers with a high player count and a bigger playable area. At ~100 Players this problem occurs several times a day. With 10 players this problem might never occur.
What causes this?
The background process that saves already unloaded chunk-data to the specific regionfiles (.mca). This is happening because the service handling the currently opened regionfiles hands out references to files. This breaks synchronization-protocol.
Was this reported before?
Yes, several times without the knowledge of why, where or cause. An example would be MC-10976
Why a new report?
This report contains exact information as to why this happens and how to fix this.
Technical background information
I am using the spigot-namings. See my report here for additional information: https://hub.spigotmc.org/jira/browse/SPIGOT-2385
- FileIOThread is the BackgroundService to save already unloaded Chunks to the specific RegionFile. This service is async
- RegionFileCache holds a bunch of cached RegionFiles for loading/unloading data. FileIOThread regularly inserts data via this. Here is the problem, RegionFileCache hands out references to files!
- ChunkRegionLoader uses RegionFileCache for different lookups/loading/unloading. For example it checks if a chunk already exists in a region file or not very frequently.
When does this problem occur?
Exactly when the RegionFileCache is viewed as "full" and a cleanup is triggered. The cleanup will remove all references to regionfiles from the RegionFileCache and close all regionfiles.
FileIOThread tries to saves data every X milliseconds to a regionfile.
If it already started a new try to save data - thus getting a reference to a file from ChunkRegionLoader - and directly after this the RegionFileCache cleanup is started then the data FileIOThread is saving in that moment will be lost. Additionally it is possible the data gets corrupted and minecraft will generate a fresh chunk at that location the next time it is requested.
How to reproduce?
As a developer this is very easy. Change the RegionFileCache limit from 256 to 2. This will heavily increase the frequency this problem occurs. This should be enough to spam the console with saving-errors.
Reprodution of chunk-regenerations
The best way is to change the limit to 2 as seen above
- Create a flat world and generate enough chunks in an area
- Create a normal world
- Copy all the regionfiles from the flat world to the normal world (dont overwrite the level.dat)
- Start up the server and fly around in gamemode 3.
- The console will be full of errors. About every 1-2 minutes there will be a newly generated chunk will appear in the previously flat area.
How to fix the synchronization/reference problem?
One way to fix this to no longer give out references to files that could be unloaded at any time. Instead the service managing the references should be the only one to know about them.
This is possible with relatively low effort.
As the general implementation of RegionFileCache is faulty the method "c" and "d" need to be rewritten. They are the problem as they hand out references to region files. Instead we can change them to hand out the NBTData directly and mark them syncronized. With this setup the syncronization actually works:
Here is an example that has been tested. Only ~10 lines of code need to be changed in total.
Current implementation
// Kade possibly broken by FileIOThread! too @Deprecated public static DataInputStream c(File file, int i, int j) { RegionFile regionfile = a(file, i, j); return regionfile.a(i & 31, j & 31); } // Kade is broken by FileIOThread! This will return a reference to a file that may be removed before it is used! @Deprecated public static DataOutputStream d(File file, int i, int j) { RegionFile regionfile = a(file, i, j); return regionfile.b(i & 31, j & 31); }
Fixed implementation
public static synchronized NBTTagCompound fixedc(File file, int i, int j) throws IOException {
RegionFile regionfile = a(file, i, j);
DataInputStream datainputstream = regionfile.a(i & 31, j & 31);
if (datainputstream == null) return null; // ChunkRegionLoader loadChunk
return NBTCompressedStreamTools.a(datainputstream);
}
public static synchronized void fixedd(File file, int i, int j, NBTTagCompound nbttagcompound) throws IOException {
RegionFile regionfile = a(file, i, j);
DataOutputStream dataoutputstream = regionfile.b(i & 31, j & 31);
NBTCompressedStreamTools.a(nbttagcompound, (DataOutput) dataoutputstream); // from ChunkRegionLoader b(...)
dataoutputstream.close();
}
Let me know if additional information is needed.
Fixed in Spigot:
https://hub.spigotmc.org/jira/browse/SPIGOT-2385
https://hub.spigotmc.org/stash/projects/SPIGOT/repos/craftbukkit/commits/7f1a32252b4fc48bad17ab3e1fc0399ce451f15e
Confirmed for
- 1.8.7 However I cannot reproduce it in the way Kademlia did
How to reproduce:
- Open server list
- Press F5 until the servers are all marked as "pinging" and it stays like this for a while
- Click on the "Play" arrow on one of the server images and press ESC at the same time (You should now be in the main menu of Minecraft)
- Click "Multiplayer" and select any other server
Note: The client doesn't even cancel the updates when leaving the latest server and entering singleplayer but instead uses the same packages which causes the player to be teleported for example
java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException at bcy.a(SourceFile:964) ~[1.8.7.jar:?] at gq.a(SourceFile:45) ~[1.8.7.jar:?] at gq.a(SourceFile:10) ~[1.8.7.jar:?] at fh$1.run(SourceFile:13) ~[1.8.7.jar:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_25] at g.a(SourceFile:60) ~[1.8.7.jar:?] ... 3 more [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException at bcy.a(SourceFile:600) ~[1.8.7.jar:?] at hu.a(SourceFile:41) ~[1.8.7.jar:?] at hu.a(SourceFile:8) ~[1.8.7.jar:?] at fh$1.run(SourceFile:13) ~[1.8.7.jar:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_25] at g.a(SourceFile:60) ~[1.8.7.jar:?] ... 3 more [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException [14:41:33] [Client thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25] at g.a(SourceFile:61) [1.8.7.jar:?] at ave.av(SourceFile:880) [1.8.7.jar:?] at ave.a(SourceFile:325) [1.8.7.jar:?] at net.minecraft.client.main.Main.main(SourceFile:124) [1.8.7.jar:?] Caused by: java.lang.NullPointerException at bcy.a(SourceFile:964) ~[1.8.7.jar:?] at gq.a(SourceFile:45) ~[1.8.7.jar:?] at gq.a(SourceFile:10) ~[1.8.7.jar:?] at fh$1.run(SourceFile:13) ~[1.8.7.jar:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_25] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_25] at g.a(SourceFile:60) ~[1.8.7.jar:?] ... 3 more [14:41:33] [Client thread/FATAL]: Error executing task
This relates to:
Kademlia that is very likely a different bug
Kademlia, I am not sure if teleporting away really proves that this fix works. As far as I know it takes some time for a chunk (and its entities) to unload.
Kademlia Does this still happen, in 1.10.2 as well as in the latest 1.11 snapshot (16w44a)?
I can only test in Singleplayer worlds at the moment.
I did some further testing. If a Client does not receive the "PacketPlayOutRespawn" packet this bug will not occur. The player will as a result experience various other bugs but i could confirm that this bug is specifically triggered by the PacketPlayOutRespawn Packet.
@Jarcode im talking about witholding the packet. The server will change the player but not inform the player about that change.
This results in various client-side bugs/glitches but the maps are still working as intended on the client side. Meaning the packet has this bug as a direct result - no other packets should need to be checked to fix this bug.
OT: A tip for your plugin: if you intend to support bungeecord you will need to split the MapId-Cache into parts and give all servers a section - else the players will get bugged maps once changing the servers - had the same problem.
Here is a way of easy reproduction with any client and any server:
1. Increase your lookup-time for a servers DNS/IP (see start of the video)
(This can be done by using a proxyserver and forcing DNS-Lookups via the proxy)
2. Use "REFRESH" to mark all servers as "unknown" for a little while
3. Connect to two servers shortly after another.
Video:
https://www.youtube.com/watch?v=OpsrZB0x17I
Serverlog Server 1:
Serverlog Server 2:
As far as i can tell from a heap-dump this is not the case. In 1.9.2 there are no ase.java (Chunk) classes loaded if no player is connected.
Assuming the spawn-area is always loaded this would mean there area different problems in my opinion:
1. The Server will keep chunks loaded event if no player is online. This can result in unnecessary data loss on hard shutdowns.
2. Using the worldborder will not prevent certain parts of the world to still be active.
3. There is an unnecessary amount of memory constantly being used. Which would be useful to get rid of (specifically if talking about cloud services like realms).
This issue is not fixed in 1.9.2.
https://www.youtube.com/watch?v=biQF9qu2ww8
MC-46345only refers to the maps no longer updating.This report refers to the memory never being cleared and ultimately causing a OutOfMemoryError.
A player in a team with collision disabled
(/scoreboard teams option a collisionRule pushOwnTeam)
will still be able to push teammates if riding a (horse) vehicle.
This seems to be a result of the client-sided logic of the player being pushed.
Sorry I dont understand you comment. None of your reports are even related to client-side memoryleaks and maps. For this Bug it does not matter what server you join. Just join random Servers with maps for some time and your client will crash at some point.
Hey, thank you for responding. Showing this via a worldmap would be quite difficult. I hope relating to the code helps:
This is based on the currently available minecraft_server.1.9.4.jar (and deopfuscated spigot codes)
Obfuscated:
Class: aht.java
Method (~Line 426): public int c(cl \u2603, boolean \u2603)
Deobfuscated:
Class: World.java
Method ( ~Line: 623): public int c(BlockPosition blockposition, boolean flag)
This method would be something like getMaxLightLevel(Position position, boolean firstCall).
The method will try to get the highest light level. It returns the light-level of the block itself if it has one (air/non-solid block)
or the highest of the five closest blocks (up,north,east,south,west). This second part has the problematic code.
Methodflow should be:
Chunkloads based on this code will happen every time the growth-algorithm tries to grow a plant at the border of a players visible (loaded) area.
Adding something like this code before the highlighted chunk-loading would fix this
On a side-note the same happens when trying to spread grass, mushrooms, mycel, cocoa etc.
In these files there are checks to get the blocktypes of the surrounding blocks and try to spread these blocks afterwards.
Those calls force sync-chunkloads too.
Let me know if there is something missing or additional information are needed.
Confirmed for 1.10
Confirmed 1.10; same seed same coordinates
I do not understand why you wrote this.
I understand what you are trying to say but this is still not very helpful to the ticket:
Your viewing the network/memory cost from the wrong side. By default all Sections are transferred (100% usage). Sometimes there are sections not transferred because of this faulty code (they should be anyways and everyone expects them to!). If you take typical values, lets say a viewdistance of 6 and and 5 sections each chunk. Thats 169 Chunks or 845 Sections. A missing section because of this bug is about 0,1%. This concern is not justified and even a recommendation to implement something to save 0,1% is a pretty hard sell.
As mentioned in point 4, yes it is.
Edit: I´d argue a new topic with all information is worth it, as this is neither only a single-player problem as the title suggests, nor does this only happen when quitting the game.
Possibly caused by
MC-10976. The bug described there was already present in minecraft 1.4.xHey,
I recently found and fixed this bug. This is caused by the numeric precision of float/double and is a round-off error caused by the re-initialisation of an entities bounding box when loading the entity from its NBT-Data.
An example-fix would be to save the current bounding box of an entity to the NBT Tag. But there are other ways to fix this too.
Video of the Problem in SP and the working solution on my server: https://youtu.be/jSJGQAGSmPo
@md_5 cannot reproduce with that map within ~5minutes of teleporting.
Im guessing you did not have the exact order?
setPositon(...) in the loading method MUST be called before loading the AABB data - not the other way around.
Hey,
I would still argue there is a .setPosition() in your methodflow. Try adding it right before the end of the catch block.
roundoff: Yes that is the definition of a numeric precision problem. The amount of difference is not the point. Example:
0.00000000000001 to -0.0000000000001 would completely change your program logic.
The same goes in this case.
An Entity standing somewhere at 0.5XXXX
and a BoundingBox up to 0.62499999999999998
Will be rounded to 0.625 or higher. Thus changing the actual block-location of the bounding-box test code.
In this case 0.62499999999999998 would be the maximum to not get treated as "standing on Block 1" (possibly blocktype dependent)
By rounding this up to 0.625 on re-initialisation of the BoundingBox the Entity will now be treated as "standing on Block 1" before it was only "standing on Block 0"
Updated Video with the mentioned Test-Map and latest Build: https://www.youtube.com/watch?v=-m2zcTQJ7gk
If it still happens to you if the loading-code is at the end of the method I would bet on a CPU type dependency (fastmath, SSE...) but that would really surprise me.
@Marcono1234
Teleporting is enough to produce the problem in vanilla. You can use the Test-Map in this Report to reproduce the problem with vanilla within one or two teleports.
The difference is instantly visible (Fixed spigot first, spigot normal at 30sec): https://youtu.be/zj1Y43Buyik
The question if it 'proves it works' is harder of course. But as this only happens on chunk-reloading an not in normal gameplay this problem must be generated by this entity loading mechanism. I compared all Entity fields at runtime that either changed trough saving/loading to/from NBT or are never saved.
MC-46345was marked as fixed, if this is actually the case (no version released yet) this should fixMC-80782andMC-98707too.If
MC-46345somehow does not fix the other two the severity of the memoryleak may increase greatly.As far as i can tell this was fixed with https://bugs.mojang.com/browse/MC-46345
Every version above 16w42a should be fixed currently. Thus 1.10.2 should still have the problem.
@Killerbeenl ( @Marcono1234 )
Regarding the PC-Version (I have never used the MCCE):
While this is certainly a possibility you are re-loading the world and thus the mentioned precision-problem (first mentioned here AFAIK; not by me: http://bugs.mojang.com/browse/MC-2025?focusedCommentId=74619) is sufficient to cause the problem. So I´d argue this does not indicate another problem on its own.
As far as I know vanilla MC always looks up the blocktype when moving entities and sync-loading needed chunks. But its hard to tell as servers generally pause entities on bordering chunks to keep the server from constantly loading/unloading "border+1"-chunks.
Apart from the mentioned precision-problem I fixed another related bug on my servers. This was mentioned in the comments here as well some years ago: The BoundingBox of an Entity that is changing its state from Baby to "GrownUp" increases and can result in entities moving out of fenced areas if the entity was standing directly at the fence while growing up. This can be fixed by relocating the entity in the event of growing up (my ugly code to fix this: https://hastebin.com/socaxakiko.cpp).
Since adding those two additions no player (on the servers) was able to reproduce the problem but as stated above on servers entities near the border of the loaded world wont move.
See https://hub.spigotmc.org/jira/browse/SPIGOT-1097
worldserver.flushSave(); is called by CommandSaveAll and results in a syncronous call to the mentioned method.
This can result in the creation of two iterators which are not thread safe even when using a ConcurrentHashMap and can result in at least a NPE on .next().
While I agree with most of what you said I do not agree with this conclusion:
If a 'standard hitbox sizes change due to bug fixes' the change of said hitbox will most likely not be in the range of your proposed margin of
but rather bigger than 1.0 / (1L<<6) making the solution for said problem still fail in the future, it would more ore less be the problem of growing.
("Other reasons" would have to be specified to be a valid point.)
For growing up and NBT saving see also: https://www.reddit.com/r/Mojira/comments/6tf9n7/insight_into_the_bug_fix_decisionmaking_process/dlkyqkn/
Hey,
thanks for the clarifications. As stated I am not against the idea or try to argue for the NBT-Saving idea. I just want to make sure the given reasons are valid reasons for the argument here. Lets look at the given list:
1. Issue of backwards compatibility.
I would disagree that this would be a factor talking about Minecraft.
2. Corrupted hitboxes would persist.
I would disagree with this also. The reason being that hitboxes do not 'persist'. They area changed on each tick to represent the given position and dimension of an entity. Thus always being corrected. The only reason for saving the AABB in the NBT data is because the code-flow is broken by saving/loading entities. You could probably even not save the AABB and just re-set the initial position of the entity later in the NBT-Loading method to get the same working flow again - calling .setPosition and re-calculating the AABB in the NBTLoad-Method is whats breaking said flow.
3. Any hitbox loaded would need to be corrected and as been in described in length because of the rounding artefacts would create an ambiguous state when a hitbox isn't at its correct size.
As far as i can tell this is answered with 2.? Feel free to correct me.
4. If hitboxes are corrected it could still result in the same overlapping walls problem that was started out with.
I do unfortunately not understand to what you are referring here with 'hitboxes are corrected'
5. Extra storage for no reason when a simpler solution fixes the issue.
I agree that additional storage is to be prevented but don't think its a strong point considering the amount. And I´d argue the use of 'simpler' in the sentence strongly
(6.) One of the initial arguments as I understood it is that the margin-Solution would fix changes to the Entity-Dimension made by the developers (See the quote in my last comment). As far as I can tell from your explanation this would definitely not be the case based on the defined margin-Size. If you ONLY talk about changes made to the code-flow and recalculation of position/hitboxes etc. then I´d agree.
As far as I can tell the main difference in our understanding of the code (and feel free to correct me here) is that you consider hitboxes to be fixed values in the entity while I am of the impression that they are only used as dynamically created temporary values that change each tick anyway.
Do you have a explanation what needs to actually be changed in the code to make a working build similar to my reddit-post linked above?
(@Timothy regardless of whether or not bugs get fixed I don't think you are helping yourself with the off-topic parts of the comment)
Confirmed for 1.13-pre1 see latest image