Write an automation script in your favorite language that repeatedly launches and shuts down the server. You will eventually see it along with MC-38134.
While it may be related I don't think its actually a duplicate since this issue doesn't require mobs. The clock lag can be seen in Peaceful mode with a minecart.
It happens quicker in superflat worlds, yet, I'm also getting it in a normal survival world after a couple hours or so sitting next to a clock. 15w51b
I am experiencing this in 15w51b.
Edit: Actually might be a slightly different bug than what was reported here. Since it only seems to occur when I ride away in a minecart.
For awhile now I have wondered why hoppers look for items at all. It seems to me that moving items, which already perform a number of checks for moving, could cheaply search for hoppers.
I started a test world for this issue and so far I've only been able to recreate it with pulsers and 2-on/2-off clocks connected to a bud-able mechanism or command-block. At 3+ on/off with just a clock and 1 mechanism everything runs fine for hours. I've not been able to recreate it with just a clock so I believe the issue is with rapid firing the mechanisms at or below 4 ticks.
Edit: As a note I've updated absolutely everything on my PC. I also recently tested all my hardware, and performed an intensive series of scans for malware. Not for any particular reason its just something I do every few months or so. So all is well with my old clunker.
I've also tested with both the default Java settings and Java 1.8.0_66 with the new version of CMSIncrementalMode(UseParNewGC ). 1.8.0_66 with UseParNewGC runs better, but, the issue still occurs after a bit. So its likely not an issue with Java. My most recent tests were with the default settings.
You also need to change your minecraft profile to point to a new version of java since by default it uses its own copy. Use at your own risk, as some java updates will blow minecraft up. It can be useful to make sandbox copies of any java versions that work.
Also, I spoke too soon. Update 66 definitely runs better than update 25, however, I am still getting this issue after awhile.
Actually, updating to JRE 1.8 Update 66 seems to have resolved this for me.
I've been noticing this as well on a world that hasn't been corrupted yet. It only seems to lag if the clock is connected to a mechanism. It will lag much quicker if that mechanism is also budded.
I cannot reliably test this or any other issue until MC-38134 is resolved. That said switching to UseParNewGC was a valid workaround/fix that I remember testing extensively. Thus, I doubt further testing is needed on this issue.
This is still corrupting my worlds in 15w49b.
Affects 15w49b. Still no minecraft for me.
The frequent world corruption this issue was hiding caused me to quit playing for a long time. Whenever I get back to Minecraft it will be the first thing I check.
To Michelle Foxcat: while this ticket is still incorrectly linked, MC-8471 is a better place to post concerning it.
Yeah, while I turned up some interesting looking data its not reliable enough to report. An unrelated bug makes getting clean uncorrupt worlds in 1.8.3 nigh impossible. I will say that villages are not being placed in Customized worlds regardless of Biome Size, yet all other structures listed were found at one point or another.
Exactly, the server is crashing as it saves the world yet no report is generated. If it crashes with the error I noted after "Saving players" it never gets to "Saving worlds" because its dead. Any changes that hadn't been saved to disk are lost because its dead. It crashed, but, no report was generated.
Edit: I apologize if my wording is getting funny. I've a medical condition that is starting to take effect.
I'm still trying to figure how to respond to this without being facetious. That this could be taken as a feature request would mean that the Crash Reporter was not designed or implemented with the intent of catching and reporting crashes.
Sorry was about to delete the email when noticed you wanted the game output.
Now I'm scratching my head. How is reporting a failure in the crash report system a feature suggestion?
Noticed suggestions being tossed around on this in my email. Conceptually dust has no timing, so a segmented list of dust structures would make more sense. If a dust segment/structure gets activated all input components on its list get an update scheduled in the order of distance from the activated output. In certain situations this would cause significantly more memory usage, yet, those situations should be rare. Sorry if my explanation is unclear. Communicating my thoughts is becoming increasingly more difficult.