Saposhiente
- Saposhiente
- saposhiente
- America/Los_Angeles
- Yes
- No
MC-48220
Using the "/setblock ~ ~1 ~ redstone_block 0 destroy" command in a command block, whenever the command block triggers, it will destroy and replace a redstone block powering it, causing it to trigger again, and creating a very fast clock that is very useful to power other command blocks, and that works great in 1.7.4. In these snapshots (and possibly others), after about 45 minutes of running this clock continuously (during which time the block is replaced 42.7 thousand times), the server will begin to intermittently freeze. In singleplayer, you are still able to move around (sometimes with severe lag, other times with no lag), but the clock stops, as do any mobs and other redstone circuits. Every few moments, all (or most) of the ticks that were supposed to happen while the server was frozen will happen at once, and then the server will freeze again. Attempting to place a block and then another block on top of it results in the second block disappearing the next time ticks happen, and also can lead to difficulty moving. CPU usage is at maximum; there is no significant increase in use of memory. Upon exiting the world, the main menu UI is less responsive, and closing the game takes several seconds, during which time Windows labels the process as (not responding). Attached is a video of my first encounter with the bug; I have also tested an empty world containing only this clock with no scoreboard incrementing or other redstone running and encountered the same behavior.
Using the "/setblock ~ ~1 ~ redstone_block 0 destroy" command in a command block, whenever the command block triggers, it will destroy and replace a redstone block powering it, causing it to trigger again, and creating a very fast clock that is very useful to power other command blocks, and that works great in 1.7.4. In these snapshots (and possibly others), after about 45 minutes of running this clock continuously (during which time the block is replaced 42.7 thousand times), the server will begin to intermittently freeze. In singleplayer, you are still able to move around (sometimes with severe lag, other times with no lag), but the clock stops, as do any mobs and other redstone circuits. Every few moments, all (or most) of the ticks that were supposed to happen while the server was frozen will happen at once, and then the server will freeze again. Attempting to place a block and then another block on top of it results in the second block disappearing the next time ticks happen, and also can lead to difficulty moving. CPU usage is at maximum; there is no significant increase in use of memory. Upon exiting the world, the main menu UI is less responsive, and closing the game takes several seconds, during which time Windows labels the process as (not responding). Attached is a video of my first encounter with the bug; I have also tested an empty world containing only this clock with no scoreboard incrementing or other redstone running and encountered the same behavior.
Suspected cause: Even when
Using the "/setblock ~ ~1 ~ redstone_block 0 destroy" command in a command block, whenever the command block triggers, it will destroy and replace a redstone block powering it, causing it to trigger again, and creating a very fast clock that is very useful to power other command blocks, and that works great in 1.7.4. In these snapshots (and possibly others), after about 45 minutes of running this clock continuously (during which time the block is replaced 42.7 thousand times), the server will begin to intermittently freeze. In singleplayer, you are still able to move around (sometimes with severe lag, other times with no lag), but the clock stops, as do any mobs and other redstone circuits. Every few moments, all (or most) of the ticks that were supposed to happen while the server was frozen will happen at once, and then the server will freeze again. Attempting to place a block and then another block on top of it results in the second block disappearing the next time ticks happen, and also can lead to difficulty moving. CPU usage is at maximum; there is no significant increase in use of memory. Upon exiting the world, the main menu UI is less responsive, and closing the game takes several seconds, during which time Windows labels the process as (not responding). Attached is a video of my first encounter with the bug; I have also tested an empty world containing only this clock with no scoreboard incrementing or other redstone running and encountered the same behavior.
Suspected cause: Even whenUsing the "/setblock ~ ~1 ~ redstone_block 0 destroy" command in a command block, whenever the command block triggers, it will destroy and replace a redstone block powering it, causing it to trigger again, and creating a very fast clock that is very useful to power other command blocks, and that works great in 1.7.4. In these snapshots (and possibly others), after about 45 minutes of running this clock continuously (during which time the block is replaced 42.7 thousand times), the server will begin to intermittently freeze. In singleplayer, you are still able to move around (sometimes with severe lag, other times with no lag), but the clock stops, as do any mobs and other redstone circuits. Every few moments, all (or most) of the ticks that were supposed to happen while the server was frozen will happen at once, and then the server will freeze again. Attempting to place a block and then another block on top of it results in the second block disappearing the next time ticks happen, and also can lead to difficulty moving. CPU usage is at maximum; there is no significant increase in use of memory. Upon exiting the world, the main menu UI is less responsive, and closing the game takes several seconds, during which time Windows labels the process as (not responding). Attached is a video of my first encounter with the bug; I have also tested an empty world containing only this clock with no scoreboard incrementing or other redstone running and encountered the same behavior.
Suspected cause: Even when commandBlockOutput is disabled, running this command still adds a [Server thread/INFO] : [@: Block placed] entry to the log file every time.
Using the "/setblock ~ ~1 ~ redstone_block 0 destroy" command in a command block, whenever the command block triggers, it will destroy and replace a redstone block powering it, causing it to trigger again, and creating a very fast clock that is very useful to power other command blocks, and that works great in 1.7.4. In these snapshots (and possibly others), after about 45 minutes of running this clock continuously (during which time the block is replaced 42.7 thousand times), the server will begin to intermittently freeze. In singleplayer, you are still able to move around (sometimes with severe lag, other times with no lag), but the clock stops, as do any mobs and other redstone circuits. Every few moments, all (or most) of the ticks that were supposed to happen while the server was frozen will happen at once, and then the server will freeze again. Attempting to place a block and then another block on top of it results in the second block disappearing the next time ticks happen, and also can lead to difficulty moving. CPU usage is at maximum; there is no significant increase in use of memory. Upon exiting the world, the main menu UI is less responsive, and closing the game takes several seconds, during which time Windows labels the process as (not responding). Attached is a video of my first encounter with the bug; I have also tested an empty world containing only this clock with no scoreboard incrementing or other redstone running and encountered the same behavior.
Suspected cause: Even when commandBlockOutput is disabled, running this command still adds a [Server thread/INFO] : [@: Block placed] entry to the log file every time.Using the "/setblock ~ ~1 ~ redstone_block 0 destroy" command in a command block, whenever the command block triggers, it will destroy and replace a redstone block powering it, causing it to trigger again, and creating a very fast clock that is very useful to power other command blocks, and that works great in 1.7.4. In these snapshots (and possibly others), after about 45 minutes of running this clock continuously (during which time the block is replaced 42.7 thousand times), the server will begin to intermittently freeze. In singleplayer, you are still able to move around (sometimes with severe lag, other times with no lag), but the clock stops, as do any mobs and other redstone circuits. Every few moments, all (or most) of the ticks that were supposed to happen while the server was frozen will happen at once, and then the server will freeze again. Attempting to place a block and then another block on top of it results in the second block disappearing the next time ticks happen, and also can lead to difficulty moving. CPU usage is at maximum; there is no significant increase in use of memory. Upon exiting the world, the main menu UI is less responsive, and closing the game takes several seconds, during which time Windows labels the process as (not responding). Attached is a video of my first encounter with the bug; I have also tested an empty world containing only this clock with no scoreboard incrementing or other redstone running and encountered the same behavior.
Suspected cause: Even when commandBlockOutput is disabled, running this command still adds a [Server thread/INFO] : [@: Block placed] entry to the log file every time. Eventually, this fills up the log file with so many entries that the server begins to freeze while writing the log file. This explains the behavior I've found of
Using the "/setblock ~ ~1 ~ redstone_block 0 destroy" command in a command block, whenever the command block triggers, it will destroy and replace a redstone block powering it, causing it to trigger again, and creating a very fast clock that is very useful to power other command blocks, and that works great in 1.7.4. In these snapshots (and possibly others), after about 45 minutes of running this clock continuously (during which time the block is replaced 42.7 thousand times), the server will begin to intermittently freeze. In singleplayer, you are still able to move around (sometimes with severe lag, other times with no lag), but the clock stops, as do any mobs and other redstone circuits. Every few moments, all (or most) of the ticks that were supposed to happen while the server was frozen will happen at once, and then the server will freeze again. Attempting to place a block and then another block on top of it results in the second block disappearing the next time ticks happen, and also can lead to difficulty moving. CPU usage is at maximum; there is no significant increase in use of memory. Upon exiting the world, the main menu UI is less responsive, and closing the game takes several seconds, during which time Windows labels the process as (not responding). Attached is a video of my first encounter with the bug; I have also tested an empty world containing only this clock with no scoreboard incrementing or other redstone running and encountered the same behavior.
Suspected cause: Even when commandBlockOutput is disabled, running this command still adds a [Server thread/INFO] : [@: Block placed] entry to the log file every time. Eventually, this fills up the log file with so many entries that the server begins to freezewhilewriting the log file. This explains the behavior I've found ofUsing the "/setblock ~ ~1 ~ redstone_block 0 destroy" command in a command block, whenever the command block triggers, it will destroy and replace a redstone block powering it, causing it to trigger again, and creating a very fast clock that is very useful to power other command blocks, and that works great in 1.7.4. In these snapshots (and possibly others), after about 45 minutes of running this clock continuously (during which time the block is replaced 42.7 thousand times), the server will begin to intermittently freeze. In singleplayer, you are still able to move around (sometimes with severe lag, other times with no lag), but the clock stops, as do any mobs and other redstone circuits. Every few moments, all (or most) of the ticks that were supposed to happen while the server was frozen will happen at once, and then the server will freeze again. Attempting to place a block and then another block on top of it results in the second block disappearing the next time ticks happen, and also can lead to difficulty moving. CPU usage is at maximum; there is no significant increase in use of memory. Upon exiting the world, the main menu UI is less responsive, and closing the game takes several seconds, during which time Windows labels the process as (not responding). Attached is a video of my first encounter with the bug; I have also tested an empty world containing only this clock with no scoreboard incrementing or other redstone running and encountered the same behavior.
Suspected cause: Even when commandBlockOutput is disabled, running this command still adds a [Server thread/INFO] : [@: Block placed] entry to the log file every time. Eventually, this fills up the log file with so many entries that the server begins to freeze because of writing to the log file (although it actually seems to freeze whenever Java does garbage collection, but only once latest.log has grown to 4.5-6.5 MB) This explains the behavior I've found of it persisting when exiting and reopening the world (same log file) but going away if you restart Minecraft entirely (new log file).
Using the "/setblock ~ ~1 ~ redstone_block 0 destroy" command in a command block, whenever the command block triggers, it will destroy and replace a redstone block powering it, causing it to trigger again, and creating a very fast clock that is very useful to power other command blocks, and that works great in 1.7.4. In these snapshots (and possibly others), after about 45 minutes of running this clock continuously (during which time the block is replaced 42.7 thousand times), the server will begin to intermittently freeze. In singleplayer, you are still able to move around (sometimes with severe lag, other times with no lag), but the clock stops, as do any mobs and other redstone circuits. Every few moments, all (or most) of the ticks that were supposed to happen while the server was frozen will happen at once, and then the server will freeze again. Attempting to place a block and then another block on top of it results in the second block disappearing the next time ticks happen, and also can lead to difficulty moving. CPU usage is at maximum; there is no significant increase in use of memory. Upon exiting the world, the main menu UI is less responsive, and closing the game takes several seconds, during which time Windows labels the process as (not responding). Attached is a video of my first encounter with the bug; I have also tested an empty world containing only this clock with no scoreboard incrementing or other redstone running and encountered the same behavior.
Suspected cause: Even when commandBlockOutput is disabled, running this command still adds a [Server thread/INFO] : [@: Block placed] entry to the log file every time. Eventually, this fills up the log file with so many entries that the server begins to freeze because of writing to the log file (although it actually seems to freeze whenever Java does garbage collection, but only once latest.log has grown to 4.5-6.5 MB) This explains the behavior I've found of it persisting when exiting and reopening the world (same log file) but going away if you restart Minecraft entirely (new log file). This suggests a more serious, general bug where simply running too many commands, by any means, or otherwise filling up latest.log, will cause the server to begin freezing.
Using the "/setblock ~ ~1 ~ redstone_block 0 destroy" command in a command block, whenever the command block triggers, it will destroy and replace a redstone block powering it, causing it to trigger again, and creating a very fast clock that is very useful to power other command blocks, and that works great in 1.7.4. In these snapshots (and possibly others), after about 45 minutes of running this clock continuously (during which time the block is replaced 42.7 thousand times), the server will begin to intermittently freeze. In singleplayer, you are still able to move around (sometimes with severe lag, other times with no lag), but the clock stops, as do any mobs and other redstone circuits. Every few moments, all (or most) of the ticks that were supposed to happen while the server was frozen will happen at once, and then the server will freeze again. Attempting to place a block and then another block on top of it results in the second block disappearing the next time ticks happen, and also can lead to difficulty moving. CPU usage is at maximum; there is no significant increase in use of memory. Upon exiting the world, the main menu UI is less responsive, and closing the game takes several seconds, during which time Windows labels the process as (not responding). Attached is a video of my first encounter with the bug; I have also tested an empty world containing only this clock with no scoreboard incrementing or other redstone running and encountered the same behavior.
Suspected cause: Even when commandBlockOutput is disabled, running this command still adds a [Server thread/INFO] : [@: Block placed] entry to the log file every time. Eventually, this fills up the log file with so many entries that the server begins to freeze because of writing to the log file (although it actually seems to freeze whenever Java does garbage collection, but only once latest.log has grown to 4.5-6.5 MB) This explains the behavior I've found of it persisting when exiting and reopening the world (same log file) but going away if you restart Minecraft entirely (new log file). This suggests a more serious, general bug where simply running too many commands, by any means, or otherwise filling up latest.log, will cause the server to begin freezing.
WORKAROUND: Set /gamerule logAdminCommands false
Why not both? You could keep the current behavior, but also add a new mode, perhaps call it Explore mode, where you can't modify the world in any way.
@Kumasasa I tested it individually, with no scoreboard, on 14w06b, and got the same behavior.
@Fluffy89502 No; as the video and screenshots show, I have plenty of memory remaining (about 50% is allocated when I open the world, and it climbs to only 60% allocated.)
Retested in 14w07a; still occurs, but took more time to do so, about 1 hour (this may be just random)
Confirmed in 14w21b
Tried with /gamerule logAdminCommands false and did not encounter the problem
Confirmed in 14w30c
@Kevin Taylor: In the reproduction steps, the repeater is not included in the clone source region; only the command block that is cloned, and three air blocks near it.