Minecraft 1.6.2, Minecraft 1.6.4, Minecraft 13w41b, Minecraft 1.7.1, Minecraft 1.7.2, Minecraft 13w48b, Minecraft 1.7.9, Minecraft 14w17a, Minecraft 14w21b, Minecraft 14w30c, Minecraft 14w34d, Minecraft 1.8-pre3, Minecraft 1.8, Minecraft 1.9, Minecraft 1.10.2, Minecraft 16w43a, Minecraft 16w44a, Minecraft 1.11 Pre-Release 1, Minecraft 1.11, Minecraft 16w50a, Minecraft 1.11.1, Minecraft 1.11.2, Minecraft 17w06a, Minecraft 17w13a, Minecraft 17w13b, Minecraft 17w14a, Minecraft 17w15a, Minecraft 17w16a, Minecraft 17w17b, Minecraft 17w18a, Minecraft 17w18b, Minecraft 1.12 Pre-Release 1, Minecraft 1.12 Pre-Release 2, Minecraft 1.12 Pre-Release 3, Minecraft 1.12 Pre-Release 5, Minecraft 1.12 Pre-Release 6, Minecraft 1.12 Pre-Release 7, Minecraft 1.12, Minecraft 1.12.1 Pre-Release 1, Minecraft 1.12.1, Minecraft 1.12.2 Pre-Release 1, Minecraft 1.12.2 Pre-Release 2, Minecraft 1.12.2
OS: Mac OS X (ver 10.8.4, arch x86_64)
Java: 1.6.0_51 (by Apple Inc.)
Launcher: 1.2.3 (bootstrap 4)
If you press an inventory manipulation key (Q or a number key from 1 to 9) while in an inventory and hovering over certain items in your inventory at the same time as you press a key to close the inventory (E or esc), the game crashes.
Info by pokechu22.
- Make a double chest
- Open the chest
- Put an item in the slot that your cursor defaults to in the chest (the middle slot on the bottom row)
- Press both 1 and E at the exact same time.
- If the game did not crash, reopen the chest and try again (the benefit of using that slot is that you don't need to move the mouse and thus can try repeatedly quickly; the item can be either in hotbar slot 1 or the chest slot for the game to crash)
I think this specific part of the crash report explains what's happening pretty well:
Note also the message of the exception:
Specifically, size 46. What inventory has 46 slots? Answer: the player inventory! (numbered 0 to 45).
It seems like it's trying to swap items using indexes from the old inventory within the player's inventory. This can further be seen by the positions where it crashes...
A curious property of this bug is it never happens in some inventories (such as furnaces and enchantment tables), and never happens in the first slots of any inventory.
Well, assuming that it is the case of the wrong inventory being used, a quick look at the wiki.vg article on inventories should show what slots have indexes greater than 45 in different inventories, and thus would be capable of causing crashes. There's only a few: chests (of all sizes where there's more than 1 row), chested donkeys and mules, shulker boxes, and llamas with a strength of at least 4. In all of those inventories, it can be reproduced in the 9th slot of the hotbar, and in the case of large chests can be reproduced in all of the player's inventory slots and the last 8 items of the last chest row.
If this were 1.8 (before the introduction of the offhand slot), the largest player slot would be 44 instead of 45, you'd also be able to reproduce this in crafting tables with the 9th hotbar slot, and in some more slots in other inventories.
All of this is based off of MCP for 1.10.
Adding a debug logging println into GuiContainer.keyTyped (which handles slot manipulation and inventory closing) like this can show some useful information:
Normally (when the '1' is processed before the 'e', you'd get this:
But when the game crashes, you get this:
It's running the move item action on the wrong screen, as predicted! But why is the closed screen still getting keyboard input?
Well, for whatever reason GuiScreen processes its own keyboard input:
handleInput continues running on the screen it started on, even if that screen is closed! Thus, the items are swapped when 1 is pressed, even if the screen is closed. That item swapping causes a crash, because the number of available items is smaller on the player inventory than the previous one.
The "ugly hack" fix for this would be to change handleInput to bail out early if the screen changed:
A better fix would be to remove handleInput entirely and just call handleMouseInput / handleKeyboardInput from within the same place that normal input is handled instead of having two input handling loops.