mojira.dev
MC-36883

Game freezes sporadically (0-3 fps) for varying periods of time

The game freezes sporadically, F3 shows fps dropping down from my regular 25-35 fps to 0-3 fps. These freezes reoccur in inconsistent intervals. Sometimes they happen as soon as I move, sometimes they happen while I'm standing still. At first they lasted for a short moment, then they prevented me from playing completely as I was not able to move at all. Then the freezes didn't occur for a while after I installed the Java 7 update from Oracle and I thought it was okay, but then they reappeared.

I have tried the following things:

  • Deleting the ~/Library/Application\ Support/minecraft folder to be "properly" reinstalled by the launcher

  • Downloading my server world and opened it in SSP to see if the freezes were server related (they are not, apparently)

  • Created a new world on 1.6.4 to see if the freezes occur in that version (they did not, yet world size might be a factor)

  • Upgraded my Java version from the version provided by Apple to the current version from Oracle (JDK 7u45) and made sure that the minecraft profile used the up to date java executable (veryfing in the terminal via "$ java -version
    java version "1.7.0_45"")

  • Looked at the client launcher debug output. The following lines seemed to coincide with the freezes and seem… not good:

    Client> [02:24:38] [Client thread/INFO]: Warning: Clientside chunk ticking took 1006 ms
    Client> [02:24:40] [Client thread/INFO]: Warning: Clientside chunk ticking took 1050 ms
    Client> [02:24:41] [Client thread/INFO]: Warning: Clientside chunk ticking took 1053 ms
    Client> [02:24:42] [Client thread/INFO]: Warning: Clientside chunk ticking took 1025 ms
    Client> [02:24:43] [Client thread/INFO]: Warning: Clientside chunk ticking took 1042 ms
    Client> [02:24:44] [Client thread/INFO]: Warning: Clientside chunk ticking took 1069 ms
    Client> [02:24:45] [Client thread/INFO]: Warning: Clientside chunk ticking took 1065 ms
    Client> [02:24:46] [Client thread/INFO]: Warning: Clientside chunk ticking took 1101 ms
    Client> [02:24:49] [Client thread/INFO]: Warning: Clientside chunk ticking took 1121 ms
    Client> [02:24:50] [Client thread/INFO]: Warning: Clientside chunk ticking took 1114 ms
    Client> [02:24:52] [Client thread/INFO]: Warning: Clientside chunk ticking took 1106 ms
    Client> [02:24:53] [Client thread/INFO]: Warning: Clientside chunk ticking took 986 ms
    Client> [02:24:54] [Client thread/INFO]: Warning: Clientside chunk ticking took 965 ms
    Client> [02:24:55] [Client thread/INFO]: Warning: Clientside chunk ticking took 998 ms
    Client> [02:25:01] [Client thread/INFO]: Warning: Clientside chunk ticking took 1004 ms
    Client> [02:25:02] [Client thread/INFO]: Warning: Clientside chunk ticking took 979 ms
    Client> [02:25:03] [Client thread/INFO]: Warning: Clientside chunk ticking took 974 ms
    Client> [02:25:04] [Client thread/INFO]: Warning: Clientside chunk ticking took 973 ms
    Client> [02:25:05] [Client thread/INFO]: Warning: Clientside chunk ticking took 952 ms
    Client> [02:25:10] [Client thread/INFO]: Warning: Clientside chunk ticking took 1011 ms
    Client> [02:25:12] [Client thread/INFO]: Warning: Clientside chunk ticking took 1073 ms
    Client> [02:25:13] [Client thread/INFO]: Warning: Clientside chunk ticking took 1070 ms
    Client> [02:25:14] [Client thread/INFO]: Warning: Clientside chunk ticking took 1070 ms
    Client> [02:25:15] [Client thread/INFO]: Warning: Clientside chunk ticking took 1105 ms
    Client> [02:25:16] [Client thread/INFO]: Warning: Clientside chunk ticking took 902 ms
    Client> [02:25:18] [Client thread/INFO]: Warning: Clientside chunk ticking took 1024 ms
    Client> [02:25:25] [Client thread/INFO]: Warning: Clientside chunk ticking took 1001 ms
    Client> [02:25:26] [Client thread/INFO]: Warning: Clientside chunk ticking took 990 ms
    Client> [02:25:27] [Client thread/INFO]: Warning: Clientside chunk ticking took 968 ms
    Client> [02:25:28] [Client thread/INFO]: Warning: Clientside chunk ticking took 952 ms
    Client> [02:25:30] [Client thread/INFO]: Warning: Clientside chunk ticking took 1059 ms
    Client> [02:25:36] [Client thread/INFO]: Warning: Clientside chunk ticking took 1042 ms
    Client> [02:25:37] [Client thread/INFO]: Warning: Clientside chunk ticking took 998 ms
    Client> [02:25:38] [Client thread/INFO]: Warning: Clientside chunk ticking took 1050 ms
    Client> [02:25:39] [Client thread/INFO]: Warning: Clientside chunk ticking took 1024 ms
    Client> [02:25:40] [Client thread/INFO]: Warning: Clientside chunk ticking took 1032 ms
    Client> [02:25:41] [Client thread/INFO]: Warning: Clientside chunk ticking took 972 ms
    Client> [02:25:43] [Client thread/INFO]: Warning: Clientside chunk ticking took 986 ms
    Client> [02:25:44] [Client thread/INFO]: Warning: Clientside chunk ticking took 1048 ms

Related issues

Attachments

Comments

migrated
[media][media][media]
L3viathan

I too run OS X 10.9, the same Java version (6, 64-bit) and play on the same server as the reporter, however this issue doesn't seem to affect me.

CubeTheThird

Does this occur in a specific world, or in general?

Jemus42

So far I experienced it on a specific world, but I created test worlds on both 1.6.4 and 1.7.1, where I did not have the issue.
I could provide a world download of the specific world if that would help, but because of bandwidth limitations I wouldn't want to post a public download link.

CubeTheThird

Yes if you could provide a download that would be helpful. It's likely you have a corrupted chunk in your world.

kumasasa

Please attach your world to this ticket is smaller than 10 MB or upload it to a 3rd party file hoster.

Jemus42

It is 1.1GB (sorry, it's been going since last august and I love it dearly).
Download via one of my servers where it's not a big deal if my hoster hates me:
http://dump.quantenbrot.de/latestbackup.tar.gz

EDIT for possibly relevant info:
There are multiple other players on my server with that world, and only two of them (OSX and Linux users respectively) experience issues similiar to mine, at least two others have the same OS as I do and don't have any performance issues – they even noticed improvements.

Ezekiel

Are there any spawners on this map?

Jemus42

There is a mobfarm right at west of 0,0 – yes, but it has been there for about two weeks with no issues until a few days ago. The farm design includes a clock which triggers a whole bunch of dispensers, which I also suspected to induce lag, as well as the possibly high number of entities, but the interval of freezes doesn't seem to correlate with the clock.

There also is the iron trench (giant iron golem farm, video: http://www.youtube.com/watch?v=YFaCNsuD01k) right at spawn, which has been there for well over 2 months without any issues.

Ezekiel

I recommend turning off the contraptions that could be causing it, such as the mob farm.

Jemus42

I disabled the mob farm by disconnecting the clock from the redstone line to the dispensers, and after about 15 minutes of random playing I didn't notice any issues. However, earlier I have been able to play for a while without issues, too, so I am not yet sure it's simply the mobfarm's fault. I will report back on this later, it's almost 6am here and I should get some rest.

For the record: If it really turns out to be the mobfarm's fault I feel a decent amount of shame for not thinking about testing this before opening this issue.

Fenhl (Max Dominik Weber)

I play on the same server, and only had a single lagspike so far, and the mob farm was outside my view distance (bot server-side and client-side) at the time. Not only did the FPS drop, animations (such as enchantment glow and view bobbing) also slowed down. Restarting Minecraft solved the issue for me. This seems to point to a client-side problem.

Talven81

Several questions for you...

Does the lag go away after a server restart?
Does the lag appear after walking into a certain area?
Does the lag happen at the 12 chunk line (~192 blocks) from 0,0 (or spawn area)?

L3viathan

Hi,
we (as I said, I play on the same server) did some testing and the results are weird:

After disabling the hopper clock connected to our mob farm (flushing farm with tons of dispensers), the lag seemed to be gone. While this might lead to the farm being the issue here, that is strange for several reasons:

  • not all players are affected

  • there could be too many entities causing the lag. However, entities (mobs) are being transported over a short distance, sorted and then (normally) automatically killed using a drowning trap. The entity count in the F3 screen also isn't higher than usual.

  • it could be redstone-related. The actual circuit itself is very simple: a hopper-piston ("Etho") clock feeding into a monostable circuit that sends a pulse every couple of minutes. Granted, the pulse then gets distributed to hundreds of dispensers, but not all of them firing at the same time. I don't think the redstone circuit itself could be causing the lag, as we had more complicated devices work properly without any major lag.

  • block updates: When the dispensers fire, there are a lot of block updates happening (water is spreading) which is known to cause lag. However, this should only lead to a short lag spike when the updates are happening and not to the reported 0-3fps. Other players than the ones affected don't even notice when this happens, and it's not like the unaffected players are the ones with the beastly computers.

Hope this helps...

Talven81

I have a hopper-clock setup as well, not sure this is the source though but interesting we are experiencing similar issues. Please test the things in my comment above, as well now that you mention the hopper-clock, is this hopper-clock within 12 chunks of spawn?

naturalismus

Does the lag go away after a server restart?
The server was restarted 3 times since the problem first occured, so: no.
Does the lag appear after walking into a certain area?
At least for me, it didn't go away until I left a certain area and reappeared when I reentered. (I reentered again after we deactivated the mobfarm and nothing happened, but that may be a coincidence.)
Does the lag happen at the 12 chunk line (~192 blocks) from 0,0 (or spawn area)?
I'm not sure where that line is, may lag happened around x: -100, y: 14, z: 70, so within 12 chunks.
Is this hopper-clock within 12 chunks of spawn?
Yes.

Jemus42

We've been running the server with the disabled clock (and therefore disabled mobfarm) since the last update here and the affected players didn't experience any more freezes/lag like before.
Our next step is to re-enable the clock/mobfarm to see whether the issues reoccur.

However, L3viathan's comment above remains valid: Even if the freezes are cause by the mobfarm setup, it doesn't seem to make a lot of sense, i.e. maybe there is an underlying issue that cause otherwise manageable load to… overload?

Either way, the world download I linked above has been created at the point when I created this issue and has the mobfarm enabled. If you enter the world normally you should spawn at 0,70,0 and see the mobfarm right at the east side from spawn.

StrangeOne101

I've been googling around (this problem effects me big time) and it seems to be lingering with nvidia graphics cards. I have one and on 1.6, I get around 60fps. But for 1.7, I get around 3fps.

Found a user on the minecraft forums with the same thing, too. (http://www.minecraftforum.net/topic/2079918-minecraft-17-lag/)

There's also another thread here about it. (http://www.minecraftforum.net/topic/2062038-minecraft-lag-13w41a-to-172/)

Please fix.

kumasasa

@Toby Strange:
Please force a crash by pressing F3 + C for 10 seconds while in-game and attach the crash report ([minecraft|http://hopper.minecraft.net/help/finding-minecraft-data-folder]/crash-reports/crash-<DATE>-client.txt) here.

L3viathan

I think Toby Strange's issue is not related to this: Not all of our affected users have Nvidea graphic cards and they don't get the lag constantly.

We did some more testing: What might really be the cause (although this doesn't fully explain it) are the block updates happening at the time the clock sends a pulse. There are some thousand blocks updated (water) in a short time, which could cause the lag. However, this doesn't explain why it only happens to some of us and not at all (not even a noticable drop in frames) for the other people. Also, I'm certainly no expert at game internals, but as far as I understand it, that should cause server lag, not so much client lag (the server is doing fine).

Should we also do the F3 + C thing?

kumasasa

@L3viathan: Yes, please do also a force crash (I don't assume to get any valuable information out of this, but who knows....)

StrangeOne101
kumasasa
---- Minecraft Crash Report ----
// Why did you do that?

Time: 6/11/13 2:39 PM
Description: Manually triggered debug crash

java.lang.Throwable
	at azd.o(SourceFile:1383)
	at azd.ad(SourceFile:753)
	at azd.e(SourceFile:704)
	at net.minecraft.client.main.Main.main(SourceFile:103)


A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------

-- Head --
Stacktrace:
	at biz.a(SourceFile:284)

-- Affected level --
Details:
	Level name: MpServer
	All players: 1 total; [bje['StrangeOne101'/28, l='MpServer', x=-528.22, y=64.29, z=-259.23]]
	Chunk stats: MultiplayerChunkCache: 225, 225
	Level seed: 0
	Level generator: ID 01 - flat, ver 0. Features enabled: false
	Level generator options: 
	Level spawn location: World: (-564,4,-262), Chunk: (at 12,0,10 in -36,-17; contains blocks -576,0,-272 to -561,255,-257), Region: (-2,-1; contains chunks -64,-32 to -33,-1, blocks -1024,0,-512 to -513,255,-1)
	Level time: 94235 game time, 14311 day time
	Level dimension: 0
	Level storage version: 0x00000 - Unknown?
	Level weather: Rain time: 0 (now: true), thunder time: 0 (now: false)
	Level game mode: Game mode: creative (ID 1). Hardcore: false. Cheats: false
	Forced entities: 18 total; [uq['Bat'/0, l='MpServer', x=-597.63, y=58.04, z=-308.78], uq['Bat'/1, l='MpServer', x=-600.00, y=57.85, z=-303.16], uq['Bat'/2, l='MpServer', x=-601.56, y=59.04, z=-294.16], uq['Bat'/3, l='MpServer', x=-567.63, y=67.57, z=-257.00], uq['Bat'/4, l='MpServer', x=-529.59, y=57.20, z=-291.75], uq['Bat'/7, l='MpServer', x=-503.84, y=56.00, z=-225.63], uq['Bat'/8, l='MpServer', x=-514.44, y=63.38, z=-227.75], uq['Bat'/9, l='MpServer', x=-508.47, y=58.67, z=-183.63], uq['Bat'/12, l='MpServer', x=-525.66, y=57.48, z=-248.78], uq['Bat'/13, l='MpServer', x=-516.63, y=62.17, z=-259.88], uq['Bat'/14, l='MpServer', x=-523.00, y=56.00, z=-203.66], uq['Bat'/15, l='MpServer', x=-483.41, y=57.54, z=-185.56], uq['Bat'/17, l='MpServer', x=-467.72, y=55.06, z=-207.50], uq['Bat'/19, l='MpServer', x=-482.19, y=59.67, z=-212.38], uq['Bat'/18, l='MpServer', x=-453.56, y=56.48, z=-181.63], uq['Bat'/20, l='MpServer', x=-468.63, y=57.92, z=-180.19], uq['Bat'/23, l='MpServer', x=-450.78, y=57.88, z=-221.84], bje['StrangeOne101'/28, l='MpServer', x=-528.22, y=64.29, z=-259.23]]
	Retry entities: 0 total; []
	Server brand: vanilla
	Server type: Integrated singleplayer server
Stacktrace:
	at biz.a(SourceFile:284)
	at azd.b(SourceFile:1951)
	at azd.e(SourceFile:713)
	at net.minecraft.client.main.Main.main(SourceFile:103)

-- System Details --
Details:
	Minecraft Version: 1.7.2
	Operating System: Linux (amd64) version 3.8.0-19-generic
	Java Version: 1.7.0_45, Oracle Corporation
	Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
	Memory: 173044128 bytes (165 MB) / 371720192 bytes (354 MB) up to 954728448 bytes (910 MB)
	JVM Flags: 1 total; -Xmx1G
	AABB Pool Size: 20003 (1120168 bytes; 1 MB) allocated, 2 (112 bytes; 0 MB) used
	IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
	Launched Version: 1.7.2
	LWJGL: 2.9.0
	OpenGL: Quadro NVS 285/PCIe/SSE2 GL version 2.1.2 NVIDIA 304.88, NVIDIA Corporation
	Is Modded: Probably not. Jar signature remains and client brand is untouched.
	Type: Client (map_client.txt)
	Resource Packs: []
	Current Language: English (US)
	Profiler Position: N/A (disabled)
	Vec3 Pool Size: 486 (27216 bytes; 0 MB) allocated, 24 (1344 bytes; 0 MB) used
	Anisotropic Filtering: Off (1)
kumasasa

OpenGL: Quadro NVS 285/PCIe/SSE2 GL version 2.1.2 NVIDIA 304.88, NVIDIA Corporation

That driver looks rather old, try this one: http://www.nvidia.com/download/driverResults.aspx/69372/en-us

L3viathan

We noticed our freezes often occur at a specific position in the world (at a small tree farm north of spawn).
I never had this issue before, but yesterday, when I passed the tree farm, my game froze for about 10 seconds. The mob farm was turned off at that time.

Kevin Stock

I'm having the same issue. I've attached the crash report after manually crashing the game.

Kevin Stock

I logged back in from a different minecraft installation on a different OS, had the same issue. I've attached the new manual crash log from windows 7.

I can provide the world save if needed.

Lothsahn Tonkey

This bug looks like the same issue as MC-31342 & MC-38737. I can also provide a world save that shows this problem, but creating a bunch of waterfalls in a new amplified 1.7 world did not reproduce the problem.

Lothsahn Tonkey

I also should not that this doesn't appear to be related to an Nvidia driver bug. I have an AMD video card and am seeing the problem.

Fenhl (Max Dominik Weber)

Affects snapsnot 13w47c.

Tails

Is this still a concern in the current Minecraft version 1.7.4 / Launcher version 1.3.6 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Per Thulin

I have this issue, all my friends on my server do too. I'm on windows 7, not Mac.
Issue is present in 1.7.2 and 1.7.4. Java 7.0.13 x64
The same tick message is shown in the log. The tick may take up to 3000 ms.
The issue comes sort of randomly, but is connected to certain areas of our built-up world.
Main suspect blocks are large amounts of tall falling water, and glass blocks.
I have resolved the issue for one area by deleting water. But this does happen in one area with no water also. To reproduce, make several pillars of water falling from maxheight.

rydian

Java's had about 22 updates since your version, might want to update just in case it's one of the many bugs.

naturalismus

Tails: It's still a concern. I'm now certain that the issue is related to the mobfarm, since we can reproduce lags in a certain distance to the mobfarm if it is active, and the lags don't appear if the mobfarm is inactive. (However, sometimes freezes occur in random places for no reason. Sometimes in high terrain with a lot of waterfalls.)

Lothsahn Tonkey

This happens on Java 7 Update 40. I have not yet updated my server to J7U45. I will retest on 1.7.4.

Adrian Brooks

I'm getting this same issue in my strip mine in a specific spot. FPS drops to 0. log says "[08:41:56] [Client thread/INFO]: Warning: Clientside chunk ticking took 1839 ms" repeatedly, like in the bug description. After exiting the map and reentering, the problem doesn't start back for a few seconds (giving you time to escape to a safe distance). However, if you reenter the area, the problem starts back. My mine is at y8, but going to the same coordinates at y62 does not cause the problem.

I've noticed this in other places since updating to 1.7, but this is the only spot I've been able to reproduce reliably. This is on a server.

Jemus42

Affects 14w03b… Sadly.

JB

Repeatable with Water Dispensers.
Add 1 or more to a clock circuit and make the timing of inhale\exhale faster.
Then fly or walk around the nearby or previously affected chunks to test for recheckGaps and 0 FPS lockup.

  • Clock is not main reason but helps enable the water dispenser and\or single player method of testing.
    Affects an area away from the water dispenser circuit at about 'view-distance' setting.
    This area is usually a thin straight line from North to South or West to East.
    If the line is North to South, the Issue has been found On West or East side at about 112 to 160 blocks from detection coordinate.
    If West to East then the Issue has been found on North or South side at about 112 to 160 from detected edge coordinate of dead zone.

I made a post on duplicate ticket below.

This appears to be from water changing constant direction flow or glitched water spread.
Water rapids with weird configuration spreading into each other could be one problem.
( 1 Water block goes up Stairs then back down then up, using signs to make current flow uphill. )
Also when making water walls and only place water in 4 corners of a box, letting it drop to spread fill the wall; is a possibility that I can't seem to ignore.
The issue happens randomly as if a daylight sensor or clock is activating a circuit which releases then inhales water or lava.

( I tried to delete some old information that I posted about this but it appears to still be here and locked or cannot remove.)
Ignore any comments by me that do not mention Water Spreading or Constant Water change of flow direction. ( aka spreading, seeking )

Look : MC-38100

kumasasa

Is 14w04b still affected ?

Per Thulin

Affects 14w04b too.
Screenshot http://i.imgur.com/JPSufPa.png
single and multiplayer Windows Java x64 1.7.0_45
Jemus42 please update: OS irrelevant

Jemus42

Sorry, was a little preoccupied with MC-45552 and related issues.
Just confirmed as well, issue still occurs in 14w04b.

@Per Thulin: Will do, thanks

JB

Any immediate update on this bug is much appreciated.

  • Same results either clock or lever spam on Water Dispenser.

( don't forget to scroll down on MC-38100 )

If you care to see further rambling about it.
Thanks.

Confirmed 1.5.2 and higher.

It's not java version, O\S or hardware related.

  • Can be used to sabotage, aka grief.
    1.Copy world.
    2.Open copy_of_world in editor.
    3. Replace dispensers with a piece of cow , ohh wait.
    3a. Replace dispensers with a dirt block.
    4. Save, Test

JB

Sir Jeb are you aware of this bug ?
What does < toCheckcount do ?
Interesting stuff.

Philip Cass

@JB suggestion: it might help if you were able to upload a world which exhibited this behaviour (and noted the coordinates that trigger it, natch)

Lothsahn Tonkey

Willing to provide a world download and a location. However, the download is not small. If someone wants it, please reach out to me at Lothsahn at yahoo and I can certainly provide this.

spongman

I'm getting the same thing on 1.7.4. it oscillates between 110fps and 2fps. i have a bunch of water dispensers on a clock nearby.

it has something to do with render distance. its seems as if the bug triggers when the dispensers are near the render distance boundary - when i walk away and they've just disappeared into the fog. it doesn't matter if the render distance is 2 or 16. if i'm close enough the bug doesn't happen. if i'm far enough away the bug doesn't happen. but if i'm just at the boundary then the fps drops like crazy when the water flows.

spongman

Here's a map that repros this in 1.7.4. stand in the pink wool square and set your render distance to 2.

kumasasa

Confirmed with the attached world and render distance 2

spongman

just want to clarify that this bug happens at any render distance setting. you just have to be at the correct distance from the flowing water for it to trigger.

bas van der waal

I think I have the same issue, although it looks like it gets triggered in an specific area (for me, at least). When I enter the area, about a chunk in size, I get random frame drops from ~60 to 0-5. When I then exit, they continue for a couple of seconds and then return to an steady ~60 fps.
It is a 14W10C server at the moment. The problems began in 14W9(a or b, not sure). The world has been around since 14W2 I think.

Server is Debian based, with up to date Java and drivers. Also, it seems to be client based.
Client side console: http://pastebin.com/mmeec7Va

The errors in the client side console keep coming in even while I am AFK. Server console reports nothing.

JB

April update.
RecheckGaps >toCheckCount at server view-distance then subtract 16 or 32 blocks but you have to run about 16 to 32 blocks beyond or through the dead zone and then back into the "dead zone" line slowly as you observe coordinate to detect and note the other side of "recheckGaps" debugger hits. The dead zone is usually about 10 blocks wide of an area through a single chunk row from West\East or else North\South.
If dead zone is North to South line,
problem is West or East at view-distance minus 16-32.
If dead zone is West to East line,
problem is North or South at view-distance minus 16-32.

Problem ?
Primary:
Water\Lava flow changing direction constantly. (inhale \ exhale) Water dispenser repeats it easily.
Secondary:
Water\Lava walls dropping from sky to bedrock with interference causing spreading into each other after a long fall. Put signs underneath of your water drops to "cap them".
Try to remove water walls and make clients use 2x1 water columns that must be capped as a standard.

I am deleting my January novels about this subject because they are irrelevant.

This is not to rule out clocks inside of spawn area or mine cart clocks within spawn.
Those have not been tested in a spawn area situation yet but I have tested every object and the only way I was able to repeat it was with a water dispenser inhaling and exhaling water constantly and water spreading into each other from sky to ground.

I end with a repeated and unanswered question and assure you I won't be helping with this bug any longer but instead avoiding it.
What does recheckGaps > toCheckCount do ?
dynamic lighting ? chunk.java
Thanks !

Lothsahn Tonkey

It's so frustrating that despite offers to provide worlds demonstrating the problem, detailed descriptions of the problem, and 23 votes, a significant bug like this is still present.

Shabai Liu

I had this problem with my server, and after downloading the world and deleting chunks in MCEdit, I found out that the problem was with a simple hopper timer. That is all I have to say, and I have no idea why it caused this problem. Perhaps the redstone was spread out on multiple chunks, and loading part of the redstone would make it freeze?

kumasasa

Is this still an issue in 14w29b ?
Since this ticket was related to MC-12799 (which was fixed in MC-61586), there is a chance that this issue might be fixed too.

Per Thulin

Seems to be fixed in 14w29b. FPS is smooth all the time in problem areas of my map. (Lots of block placing glitches in my test though. Single player, with a texture pack.)

??? ???

Completely agree, this makes playing some 1.8.9 servers on 1.8.9 unplayable.

Jemus42

(Unassigned)

Community Consensus

freezes, lag, multiplayer, singleplayer

Minecraft 13w43a, Minecraft 1.7, Minecraft 1.7.1, Minecraft 1.7.2, Minecraft 13w47a, ..., Minecraft 14w03b, Minecraft 14w04b, Minecraft 14w05a, Minecraft 14w10b, Minecraft 1.7.9

Minecraft 14w30b

Retrieved