Custom superflat world crashes when certain block type is chosen

Confirmed. The crash dump winds up with the following chunk of text being repeated over and over:
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)

(Insert witty comment about watching the world burn here)

I dare to say: no bug, doing stupid shit with the generator is supposed to break you hard.

After all, we are stress-testing Minecraft. 🙂

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.

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

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.

obviously it shouldn't work. but a program shouldn't allow users to do stupid stuff. programs are made for stupid users. (no offense 😛 )
all it needs is an error message before (instead of) world generation that says "bohoo! sorry, you can't do that!"

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.

@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.

That isn't nearly as bad as overloading it with impossible stuff.

How is MC-1283 duplicate of this??? It's completely different bug!

you would need mods to do that soi dont think that would be of that much concern.

@Brad: You do not need any mods to reproduce this bug. All you need to do is make a custom, superflat world.

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.
P.S: Where do the error reports appear?

@Daniel
On windows, type windows key + r to open run, then type %appdata%
Open .minecraft
Open crash-reports
The most recent one should be on the bottom.
On other operating systems, run may not exist, but appdata still does.

%appdata% is Windows only. On Linux minecraft's save location is

~/.minecraft

and on Mac it's

~/Library/Application Support/minecraft

Or you can just follow this link:
[file:///%appdata%/.minecraft/crash-reports/]
(For some reason, this may not work, just copy it into the browserbar then)

Well, I am pretty sure "%appdata%" is a global link that's used on all operating systems, not 100% sure though.

Damn, who uses recursion in worldgen? Who taught (whoever wrote superflat worldgen) programming? This is shitcode, not a simple bug.

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.

Affecting Bedrock Edition. Relates MCPE-115009 and closed as Invalid, I modifying nbt and play with bed flat. When I breaking many beds in infinite beds, the game will crash.