[MC-1510] Custom superflat world crashes when certain block type is chosen Created: 31/Oct/12 Updated: 05/Jul/21 Resolved: 08/Nov/12 |
|
| Status: | Resolved |
| Project: | Minecraft: Java Edition |
| Component/s: | None |
| Affects Version/s: | Minecraft 1.4.2 |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Zenyl | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | fire, superflat-world, world-generation | ||
| Environment: |
Put your operating system (Windows 7, Windows XP, OSX) and Java version if you know it here |
||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Confirmation Status: | Unconfirmed | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
I tried to make a superflat world, where the custom preset is set to only generate one layer of fire. After generating and loading the world, the client crashed, and this is the crashlog: ***** ---- Minecraft Crash Report ---- // Hey, that tickles! Hehehe! Time: 31-10-12 20:00 Description: Exception in server tick loop java.lang.StackOverflowError at zb.b(SourceFile:73) at za.c(SourceFile:332) at za.a(SourceFile:351) at za.a(SourceFile:338) at xe.b(SourceFile:296) at xe.e(SourceFile:343) at aiu.a(SourceFile:249) at xe.m(SourceFile:419) at xe.h(SourceFile:408) at xe.f(SourceFile:365) at xe.e(SourceFile:344) at aiu.a(SourceFile:249) ... and so on. Relevant Details: - Minecraft Version: 1.4.2 - Operating System: Windows 7 (amd64) version 6.1 - Java Version: 1.7.0_07, Oracle Corporation - Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation - Memory: 327751592 bytes (312 MB) / 681705472 bytes (650 MB) up to 954466304 bytes (910 MB) - JVM Flags: 2 total; -Xms512m -Xmx1024m - AABB Pool Size: 11 (616 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used - Is Modded: Probably not - Profiler Position: N/A (disabled) - Vec3 Pool Size: 1 (56 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used - Player Count: 1 / 8; [ih['zenyl'/0, l='Test', x=-379,50, y=0,62, z=-731,50]] - World Test Entities: 0 total; [] - World Test Players: 0 total; [] - World Test Chunk Stats: ServerChunkCache: 0 Drop: 0 - Type: Integrated Server ***** What I expected to happen was that the client would crash, which is what I got. What actually happened was that the client crashed Steps to Reproduce: This is, of course, a minor bug, but since you guys asked for bugs... |
| Comments |
| Comment by Drageon DB (Dragonborn) [ 25/Feb/21 ] |
|
Affecting Bedrock Edition. Relates |
| Comment by [Mod] Pokechu22 [ 19/Jun/19 ] |
|
If I recall the actual cause of this bug (which I last tested, oh, 6 years ago back when I knew a lot less (just look at that appdata comment...)), it's not during the world generation, but instead once the world finishes loading and things start ticking. Because when you update one of the fire blocks (or the fire block receives a random update; if you use e.g. ladders then it'll only break when updated manually), it'll update its neighbors, and then those neighbors update their neighbors, for all of them. And since all of the fire blocks are in an invalid state, they all self-destruct, and there's no end to the updating. Now, it could be implemented without recursion by queuing in a list, but there still are far too many blocks for it to finish quickly and it's probably better for it to just crash that way. |
| Comment by Vladislav Toncharov [ 19/Jun/19 ] |
|
Damn, who uses recursion in worldgen? Who taught (whoever wrote superflat worldgen) programming? This is shitcode, not a simple bug. |
| Comment by [Mod] Pokechu22 [ 01/Jul/13 ] |
|
Well, I am pretty sure "%appdata%" is a global link that's used on all operating systems, not 100% sure though. |
| Comment by [Mod] Pokechu22 [ 01/Jul/13 ] |
|
Or you can just follow this link: |
| Comment by Tavis [ 01/Jul/13 ] |
|
%appdata% is Windows only. On Linux minecraft's save location is ~/.minecraft and on Mac it's ~/Library/Application Support/minecraft |
| Comment by [Mod] Pokechu22 [ 01/Jul/13 ] |
|
@Daniel |
| Comment by Dan Taylor [ 20/Jun/13 ] |
|
I had the same problem. But with "Snow" (Decoration) as the only layer. Destroyed one "Snow" & the game crashed. No error report came up (I don't think). Went back on & there was a chunk of 1 line missing, starting from where I hit it. |
| Comment by Rolf Campbell [ 22/Mar/13 ] |
|
@Brad: You do not need any mods to reproduce this bug. All you need to do is make a custom, superflat world. |
| Comment by Brad McFarland [ 22/Mar/13 ] |
|
you would need mods to do that soi dont think that would be of that much concern. |
| Comment by Rolf Redford [ 27/Jan/13 ] |
|
How is |
| Comment by FireHunterX [ 10/Jan/13 ] |
|
That isn't nearly as bad as overloading it with impossible stuff. |
| Comment by Tavis [ 09/Jan/13 ] |
|
@Xavier I'd say it's more like a car exploding if you tilt the seat too far forward and turn the steering wheel to the left while the parking brake is on. It would be terrible if your entire web browser crashed because you put a "~" between the "http" and the "://" or executed an infinite loop in some javascript somewhere. Errors that can be handled gracefully should be, preferably returning the game to a functioning state, even if that's just the main menu or a screen with a button to get there. |
| Comment by Rolf Campbell [ 06/Jan/13 ] |
|
This bug is no longer just about one layer of fire. My bug was marked as a duplicate of it (6432), which involved creating a super-flat that had a layer of tripwires. I was trying to see if zombie pigmen would spawn on (really in) tripwires. The easiest way for me to check was to create a superflat world with a layer of tripwires and set the biome to 8 (Nether). I did the same thing for half-slabs and pressure plates (no spawns on either of those). It may not be possible to have a real world with just fire, but I could certainly have a real world with many, many tripwires. I would hope that would work. |
| Comment by Hegymegi K. Áron [ 25/Dec/12 ] |
|
obviously it shouldn't work. but a program shouldn't allow users to do stupid stuff. programs are made for stupid users. (no offense |
| Comment by FireHunterX [ 18/Dec/12 ] |
|
According to you, LordAro, the game should not crash even if you make it do impossible stuff. That's like saying a car should still work after you total it. It's not going to happen. User error is not a valid bug. Grum is right. |
| Comment by LordAro [ 14/Nov/12 ] |
|
I strongly disagree that this is not a bug - the client should never crash, it should always handle user errors gracefully In this case, making sure that selected blocks in the menu are not all transparent would suffice, i'd have thought |
| Comment by DiEvAl [ 11/Nov/12 ] |
|
1 fire disappears, updates fire blocks next to it, they also disappear, update blocks next to them... This repeats infinitely. This is supposed to happen. The bug is that it would take infinite time to do this, so it crashes. It'd be pretty difficult (if possible at all) to change infinite number of blocks in a finite time, and it wouldn't be ever used by sane players, so I agree with Grum. |
| Comment by Tom Lee [ 08/Nov/12 ] |
|
After all, we are stress-testing Minecraft. |
| Comment by [Mojang] Grum (Erik Broes) [ 08/Nov/12 ] |
|
I dare to say: no bug, doing stupid shit with the generator is supposed to break you hard. |
| Comment by Chalmes (Jon) [ 31/Oct/12 ] |
|
Confirmed. The crash dump winds up with the following chunk of text being repeated over and over: (Insert witty comment about watching the world burn here) |