Brandon Enright
- bmenrigh
- bmenrigh
- Etc/GMT
- Yes
- No
MC-830
MCL-15340
Desert Temple TNT trap may detonate prematurely
For many versions (going back to at least 1.0), the fullscreen that I get from F11 is not usable because I can only look/turn 180 degrees total. If I keep moving the mouse right (or left) the view will stop rotating. I have assumed this is a feature.
The fullscreen video setting added in 1.4.2 does not have this problem and is fully playable.
The only reason this matters much is that switching in and out of fullscreen using the menu setting is cumbersome and the F11 shortcut would be very convenient. When I ALT-Tab out of Minecraft the fullscreen drops back to normal window mode without updating the fullscreen video setting to off. To get fullscreen back I have to toggle it off and on.
64bit Oracle Java 1.7.0_09 on Linux.
For many versions (going back to at least 1.0), the fullscreen that I get from F11 is not usable because I can only look/turn 180 degrees total. If I keep moving the mouse right (or left) the view will stop rotating. I have assumed this is a feature.
The fullscreen video setting added in 1.4.2 does not have this problem and is fully playable.
The only reason this matters much is that switching in and out of fullscreen using the menu setting is cumbersome and the F11 shortcut would be very convenient. When I ALT-Tab out of Minecraft the fullscreen drops back to normal window mode without updating the fullscreen video setting to off. To get fullscreen back I have to toggle it off and on.
64bit Oracle Java 1.7.0_09 on Linux.
brenrigh@lambda ~ $ java -version
java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)brenrigh@lambda ~ $ uname -a
Linux lambda 3.5.0 #1 SMP PREEMPT Tue Aug 7 00:12:55 UTC 2012 x86_64 Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz GenuineIntel GNU/Linuxbrenrigh@lambda ~ $ java -jar download/minecraft.jar
27 achievements
208 recipes
Setting user: bmenrigh, <hex that might be sensitive>
LWJGL Version: 2.8.4X.Org X Server 1.12.2
Release Date: 2012-05-29
Brandon Enright, this issue is caused by lag, as lag is the only thing that causes a reduced tickrate, which triggers Watchdog. I am pointing out a likely chain for the lag cause.
Brandon Enright:
It is about lag, and that can be caused by several things. The zombie pathfinding is probably one of the largest problems though.
Saying that a "cant keep up" message has nothing to do with any mob is just stupid and can be explored by putting 10000000 mobs in a world and see what happens.
StevenNL2000:
I agree.. The zombie pathfinding algorithm is probably one of the largest problems causing lag atm due to the way it grows.
(Of course that is not the only problem causing lag, but its would be a good start to optimize this)
Edit: Ops.. Did not see your last post before posting this.
I doubt it's just one thing that needs fixing. I suspect a lot of effort needs to go into using less memory and probably also less CPU
the load has nothing to do with any mobs
Therefore mobs aren't the root cause of the issue even if they may make it worse.
Look at your own posts...
Also... I don not know if I ever said that it was the "root" of the problem. Did i?
Edit:
Your posts so far have been good, so lets not go on in a tangent here and instead focus on the problem. I have since long been trying to put some light on G1GC for example, so I agree with you on a lot of things.
Brandon Enright, Pierre Waldén, it seems that docm77 found one cause of the lag at https://twitter.com/docm77/status/512882629184454656.
Brandon Enright: Please keep it civil and don't call others idiot.
Gotcha. That's somewhat likely too since I'm on peaceful but have spawn-monsters on so they blink in and out of existence like crazy.
A few troubleshooting suggestions:
Can you press CTRL+ALT+F1 to switch to a virtual terminal? If not, can you start an SSH server and try connecting to your frozen machine remotely?
If you can do either of these then you should be able to get a stack trace of the Java process for troubleshooting. Use "jstack":
brenrigh@lambda ~ $ jstack --help
Usage:
jstack [-l] <pid>
(to connect to running process)
jstack -F [-m] [-l] <pid>
(to connect to a hung process)
jstack [-m] [-l] <executable> <core>
(to connect to a core file)
jstack [-m] [-l] [server_id@]<remote server IP or hostname>
(to connect to a remote debug server)
Options:
-F to force a thread dump. Use when jstack <pid> does not respond (process is hung)
-m to print both java and native frames (mixed mode)
-l long listing. Prints additional information about locks
-h or -help to print this help message
You should also be able to kill the process, or kill X and recover your machine without rebooting. Of course if your kernel is hung then none of these options will work. In that case, try enabling the Magic SysReq key. Take a look at the documentation in /usr/src/linux/Documentation/sysrq.txt
You can probably dump a kernel stack trace which will help if this is related to a video card driver issue.
If not, at least the Magic SysReq will let you try to sync your disks and remount everything RO before rebooting.
I updated to Xorg 1.13 and updated my Nvidia drivers to 304.60 and Minecraft to 1.4.4 and the issue is still occurring.
To be clear, with F11 it is like I'm only turning my head and not my whole body. I can only look right 90 degrees and only look left 90 degrees.
I liked the sound but I don't much care if it stays or not. I'm still hearing the sound when other players level up every 5 and are close to me. Seems inconsistent that I hear it for other players but not for myself. Perhaps they hear me level up but they don't hear themselves?
This isn't a duplicate of any other issue I've seen, including
MC-229. Others have reported MC crashing or not updating the menu, etc. Yes I have those problems but nobody has described the 180 degree view limitation. I don't have any graphical glitches, MC doesn't hang, I don't have any problems with F11 other than my character can only turn +90 and -90 in the horizontal direction.This is the nature of randomness. I've seen so many strange things that are unusual but they aren't bugs. On my current world I've found a location with six different ravines that all intersect each other in a single chunk.
Interesting. If I press F11 when the MC window is in focus, I'm limited to 90 degrees in each direction. If I click (as to select the full screen window) then I can play normally. It is as though F11 doesn't maintain the focus of the window. MC will have focus but when I press F11 it doesn't have focus until I click again to gain focus.
I'm not sure if MC can maintain focus when I press F11 or not (that is, if Xorg will allow it) but I'd say this "bug" is resolved in that clicking to gain focus takes care of the problem.
The description that an entire chunk doesn't display is not completely accurate. The screenshots of this bug that look down at the ground and can see through to caves make it look as though an entire chunk isn't rendering. If you look at the screenshots I provided in
MC-10846you can see that sometimes it's just a portion of a chunk that disappears. The top of the tree goes away but the trunk and everything below the top that is all part of the same chunk are still drawn.Perhaps the game further subdivides chunks? Possibly into 16x16x16 cubes?
Also, this bug is not dependant on moving your position. It's easiest to trigger moving back and forth but you can also trigger it by standing in a single location an moving your view.
Reloading chunks with F3 + a has no effect on the bug.
I suspect this bug is probably a failure in z-ordering and occlusion / culling of backfaces of an algorithm such as "Painter's Algorithm": https://en.wikipedia.org/wiki/Painter%27s_algorithm
This bug might just be an edge case in the algorithm where it incorrectly removes or incorrectly orders the drawing of regions because getting the z-ordering correct is difficult?
Added screenshot where tree top in back left is visible.
Added screenshot where tree top in back left has disappeared. The trunk of the tree is still visible implying that at least some of the chunk is still being rendered.
I just tested in 1.5 and indeed the same portion of the tree disappears in the same location in the same way. Advanced OpenGL still toggles the bug. Note that I'm using Linux even though the OS for this bug is set to OS X. I will attach a crash report when the tree top is missing however I perused the crash report and don't see much of anything useful.
Crash report taken while tree top was missing.
Óscar does turning off Advanced OpenGL toggle that issue on and of? Also, does slightly changing your view or the location you stand toggle the issue?
I'm pretty sure the issue you're seeing has to do with chunks not loading or being processed by your client fast enough. For example, if you're playing on a server and your client cant download chunks fast enough you'll see holes like this.
The issue Hiram and I are describing is always reproducible, can be toggled back and forth by minor changes in a players position and view, and goes away when Advanced OpenGL is turned off. As long as the player's perspective stays the same portions of the chunks will not be rendered. The issue won't go away by waiting.
You should try pressing F3 and a to reload chunks to see if that makes your issue go away.
@Nathan Gorzelanczyk I think Mojang deserves a bit more credit. I think they know how to fix the majority of these old bugs but the fix is too computationally costly. This is especially true with the lighting issues.
CPU time spend doing bounding box and collision checks is time not spent rendering and performing other actions. Java isn't exactly snappy and the average MC player's computer isn't a gaming rig. I think they're doing their best.
Glitching out and teleporting backe is not the issue. That's a purely client-side problem.
The issue is that mobs can actually escape fences permanently. I've never seen it happen while all of fenced area chunks are loaded and nearby. I think the issue of mobs escaping only happens when chunks containing portions of the fence are unloaded and then reloaded. Most likely animals pushed up against the fence when the chunk is unloaded will either load on the other side of the fence when the chunk is reloaded or, perhaps breaks in the fence due to unloaded chunks allow animals to walk out.
Ryan, yes, I see this bug is specifically about the mobs appearing to come out of the fence only to zip back in later. Mobs escaping permanently is a different issue. Any idea what the bug ID for that one is?
Hmm that's pretty bad. What hash is being applied to X ^ Y? Is it just a Java built-in? Are X and Z floats?
An affine transform like AX + Z mod N would probably do a lot better. Have you tested various options?
This is still happening in 1.6.1 in the same place as my screen shot.
This is still easily reproducible in the latest snapshot (13w38c) in the same location as my screenshot and previous tests. "Advanced OpenGL" still toggles it. The other changes in rendering don't seem to have any effect.
It's not clear if this really is "works as intended" / "won't fix". It's entirely likely that gravel is just a placeholder until they figure out what they want to do with the ocean floor. I think this should be left open until a dev chimes in. The worst that can happen is a dev has to spend 10 second closing the bug.
Hi Grum, please ignore how rude Alex was.
These days, most programming languages are using SipHash (Google it) for their hashtables / associate arrays / dictionaries. It's secure against even malicious manipulation.
Since your input to the hash is very small (an int) this is overkill. Instead I'd suggest a simple affine transform on X and Z and then XOR them together. If look up "Linear congruential generator" the Xn = (A* X(n-1) + C) mod M transform works well, especially if you choose A and C so that the transform is a bijective mapping. You can use the "Numerical Recipies" constants of A = 1664525; C = 1013904223; M = 2^32
I'd suggest XORing X and Y before the transform, and then XORing the transformed results:
hash = ((1664525 * (X ^ 0xdeadbeef) + 1013904223) & 0xFFFFFFFF) ^ ((1664525 * (Y ^ 0xbabecafe) + 1013904223) & 0xFFFFFFFF)
You can truncate this hash to however many bits you actually need for your table.
Yes I saw https://twitter.com/Dinnerbone/status/491953005776748544 this morning "We'll release a 'b' snapshot soon to fix the chunk-vanishing issue (and some crashes)". I will test and report back in a day or two.
I reported what sounds like the same issue in
MC-56743My 1.8 (release version) server is experiencing the same issue. The 1.7.10 release ran great but now the same world in 1.8 is unplayable. The server can't keep up and the console is flooded with:
[05:16:19] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 18861ms behind, skipping 377 tick(s)
[05:16:21] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2176ms behind, skipping 43 tick(s)
[05:17:06] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 26332ms behind, skipping 526 tick(s)
[05:17:08] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2384ms behind, skipping 47 tick(s)
[05:18:00] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 32211ms behind, skipping 644 tick(s)
[05:18:02] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2818ms behind, skipping 56 tick(s)
[05:19:08] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 39414ms behind, skipping 788 tick(s)
[05:19:10] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2278ms behind, skipping 45 tick(s)
[05:20:17] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 39530ms behind, skipping 790 tick(s)
[05:20:19] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2267ms behind, skipping 45 tick(s)
[05:21:07] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 29640ms behind, skipping 592 tick(s)
[05:21:09] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2595ms behind, skipping 51 tick(s)
[05:21:54] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 25908ms behind, skipping 518 tick(s)
[05:21:56] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2195ms behind, skipping 43 tick(s)
My 1.8 (release version) server is experiencing the same issue. The 1.7.10 release ran great but now the same world in 1.8 is unplayable. The server can't keep up and the console is flooded with:
[05:16:19] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 18861ms behind, skipping 377 tick(s)
[05:16:21] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2176ms behind, skipping 43 tick(s)
[05:17:06] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 26332ms behind, skipping 526 tick(s)
[05:17:08] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2384ms behind, skipping 47 tick(s)
[05:18:00] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 32211ms behind, skipping 644 tick(s)
[05:18:02] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2818ms behind, skipping 56 tick(s)
[05:19:08] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 39414ms behind, skipping 788 tick(s)
[05:19:10] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2278ms behind, skipping 45 tick(s)
[05:20:17] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 39530ms behind, skipping 790 tick(s)
[05:20:19] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2267ms behind, skipping 45 tick(s)
[05:21:07] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 29640ms behind, skipping 592 tick(s)
[05:21:09] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2595ms behind, skipping 51 tick(s)
[05:21:54] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 25908ms behind, skipping 518 tick(s)
[05:21:56] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2195ms behind, skipping 43 tick(s)
@Sonic No, it's not a dupe. Read the whole report please.
No, this is a report saying the server doesn't function even with the watchdog timer disabled (max-tick-time=-1).
That is, the report is not about the server crashing due to the watchdog, the report is the server performance change in 1.8
If I leave the watchdog timer at the default 60 seconds sometimes my server will kill itself in a few minutes, before any player has attempted to join. I've also noticed that upon starting, the 1.8 server sits at 100% CPU for much, much longer than the 1.7.10 server did.
I was wondering if the performance change was due to some syscall latency like a change in disk reads or something. I used strace to track system calls and track the time spent in them with the following command:
strace -tt -T -ff -o traces/trace_start java -Xms1280M -Xmx1280M -jar minecraft_server.jar nogui
I then wrote a script to process the results. There is no meaningful difference in the syscall activity between 1.7.10 and 1.8. Here is 1.7.10:
$ cat ~/backup_1.7.10_world/current_world/traces/* | ~/current_world/sort_strace.pl | head -n 10
func: futex; total time: 2135.280352 (82.832%); count: 37192 (6.159%); median time: 0.000081; average time: 0.05741236
func: read; total time: 228.799741 (8.876%); count: 236153 (39.105%); median time: 0.000020; average time: 0.00096886
func: epoll_wait; total time: 181.589652 (7.044%); count: 184 (0.030%); median time: 1.001637; average time: 0.98690028
func: clock_gettime; total time: 23.074748 (0.895%); count: 265244 (43.922%); median time: 0.000018; average time: 0.00008699
func: gettimeofday; total time: 4.432616 (0.172%); count: 18010 (2.982%); median time: 0.000019; average time: 0.00024612
func: lseek; total time: 1.448669 (0.056%); count: 10587 (1.753%); median time: 0.000019; average time: 0.00013683
func: sched_yield; total time: 1.058822 (0.041%); count: 19273 (3.191%); median time: 0.000017; average time: 0.00005494
func: write; total time: 0.418092 (0.016%); count: 8584 (1.421%); median time: 0.000022; average time: 0.00004871
func: open; total time: 0.389138 (0.015%); count: 1260 (0.209%); median time: 0.000025; average time: 0.00030884
func: mprotect; total time: 0.345825 (0.013%); count: 3010 (0.498%); median time: 0.000026; average time: 0.00011489
And here is the syscall activity for 1.8:
$ cat traces/* | ~/current_world/sort_strace.pl | head -n 10
func: futex; total time: 2794.826033 (84.472%); count: 51580 (7.825%); median time: 0.000079; average time: 0.05418430
func: read; total time: 266.182423 (8.045%); count: 232272 (35.237%); median time: 0.000020; average time: 0.00114599
func: epoll_wait; total time: 206.683876 (6.247%); count: 211 (0.032%); median time: 1.002230; average time: 0.97954444
func: clock_gettime; total time: 28.869215 (0.873%); count: 302261 (45.855%); median time: 0.000018; average time: 0.00009551
func: gettimeofday; total time: 4.980315 (0.151%); count: 17446 (2.647%); median time: 0.000019; average time: 0.00028547
func: madvise; total time: 2.402947 (0.073%); count: 1430 (0.217%); median time: 0.000052; average time: 0.00168038
func: sched_yield; total time: 1.280591 (0.039%); count: 30288 (4.595%); median time: 0.000017; average time: 0.00004228
func: open; total time: 1.029462 (0.031%); count: 973 (0.148%); median time: 0.000028; average time: 0.00105803
func: lseek; total time: 0.730414 (0.022%); count: 10620 (1.611%); median time: 0.000018; average time: 0.00006878
func: mprotect; total time: 0.554859 (0.017%); count: 2083 (0.316%); median time: 0.000025; average time: 0.00026637
I ran each server until the world was fully loaded and the CPU usage dropped down to idle levels.
So the performance issue doesn't appear to be the result of disk reads or other OS-dependent activities.
EDIT: Yuck, the formatting got destroyed when I pasted it into Jira. Sorry. I will attach a screenshot.
The previous comments mentioning turning off mob spawning have no effect on my server. It lags just as much on peaceful and with mob spawning off.
I always launch with nogui. My script runs:
java -Xms1280M -Xmx1280M -jar minecraft_server.jar nogui
I decided to explore garbage collector options and I've found that using the G1 garbage collector (using the flag -XX:+UseG1GC) makes the problem significantly better.
I think garbage collection is the source of the terrible performance and very long lags. What's probably happening is that the server now requires more CPU and memory than it used to require. When a garbage collection happens it takes so long that the server gets behind. When the garbage collection finishes the server detects that it's behind and tries to "catch up" by skipping ticks. This in turn probably causes another garbage collection and so the server gets stuck in an vicious loop where garbage collections cause the server to do work that causes another garbage collection and so forth. Instead of getting useful work done it spend almost all of its time in garbage collection cycles.
The G1 garbage collector is designed to spread the garbage collection work out and not cause long delays which seems to prevent the vicious garbage collection cycle from killing performance.
With G1 now my server just runs slowly with lag at all times. It is now playable, but just barely.
I doubt it's just one thing that needs fixing. I suspect a lot of effort needs to go into using less memory and probably also less CPU so that garbage collection isn't needed so often and when it does happen, there is enough spare CPU left for the garbage collection to not get the server too behind. Right now I think the server can't even keep up without garbage collection so any time spent doing garbage collection means the server gets behind.
I decided to explore garbage collector options and I've found that using the G1 garbage collector (using the flag -XX:+UseG1GC) makes the problem significantly better.
I think garbage collection is the source of the terrible performance and very long lags. What's probably happening is that the server now requires more CPU and memory than it used to require. When a garbage collection happens it takes so long that the server gets behind. When the garbage collection finishes the server detects that it's behind and tries to "catch up" by skipping ticks. This in turn probably causes another garbage collection and so the server gets stuck in an vicious loop where garbage collections cause the server to do work that causes another garbage collection and so forth. Instead of getting useful work done it spend almost all of its time in garbage collection cycles.
The G1 garbage collector is designed to spread the garbage collection work out and not cause long delays which seems to prevent the vicious garbage collection cycle from killing performance.
With G1 now my server just runs slowly with lag at all times. It is now playable, but just barely.
I doubt it's just one thing that needs fixing. I suspect a lot of effort needs to go into using less memory and probably also less CPU so that garbage collection isn't needed so often and when it does happen, there is enough spare CPU left for the garbage collection to not get the server too behind. Right now I think the server can't even keep up without garbage collection so any time spent doing garbage collection means the server gets behind.
I have always run with nogui. The performance problems are intolerable even with nogui specified.
@StevenNL2000 except that the first bug is about zombies and the second is about animals and other mobs and plenty of people have tested this bug and the load has nothing to do with any mobs. Turning off mob spawning and killing all mobs has no effect.
Don't be fooled by idiots posting in this bug about how they tracked the issue down to <simple fix here> because it isn't mobs or nogui.
@Pierre Waldén
Turning off mob spawning and killing all mobs still results in the problem. Therefore mobs aren't the root cause of the issue even if they may make it worse.
You've committed a logical fallacy known as "affirming the consequent" (look it up). Next time try not to be an idiot.