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.