Crash on pressing the inventory close key and an item manipulation key at the same time in large chests
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 [Mod] Pokechu22.
To reproduce
- 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)
Speculations on the cause
I think this specific part of the crash report explains what's happening pretty well:
-- Affected screen --
Details:
Screen name: ~~ERROR~~ NullPointerException: null
Note also the message of the exception:
java.lang.IndexOutOfBoundsException: Index: 53, Size: 46
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...
Which slots cause crashes, exactly?
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.
Code analysis
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:
protected void keyTyped(char typedChar, int keyCode) throws IOException { System.out.println("Key '" + typedChar + "' typed in " + this + " - active is " + this.mc.currentScreen + " (same = " + (this.mc.currentScreen == this) + ")"); // Regular code... if (keyCode == 1 || keyCode == this.mc.gameSettings.keyBindInventory.getKeyCode()) { this.mc.thePlayer.closeScreen(); } this.checkHotbarKeys(keyCode); if (this.theSlot != null && this.theSlot.getHasStack()) { if (keyCode == this.mc.gameSettings.keyBindPickBlock.getKeyCode()) { this.handleMouseClick(this.theSlot, this.theSlot.slotNumber, 0, ClickType.CLONE); } else if (keyCode == this.mc.gameSettings.keyBindDrop.getKeyCode()) { this.handleMouseClick(this.theSlot, this.theSlot.slotNumber, isCtrlKeyDown() ? 1 : 0, ClickType.THROW); } } }
Normally (when the '1' is processed before the 'e', you'd get this:
Key '1' typed in net.minecraft.client.gui.inventory.GuiChest@77f36fa7 - active is net.minecraft.client.gui.inventory.GuiChest@77f36fa7 (same = true) Key 'e' typed in net.minecraft.client.gui.inventory.GuiChest@77f36fa7 - active is net.minecraft.client.gui.inventory.GuiChest@77f36fa7 (same = true)
But when the game crashes, you get this:
Key 'e' typed in net.minecraft.client.gui.inventory.GuiChest@685af84b - active is net.minecraft.client.gui.inventory.GuiChest@685af84b (same = true) Key '1' typed in net.minecraft.client.gui.inventory.GuiChest@685af84b - active is null (same = false)
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:
/** * Delegates mouse and keyboard input. */ public void handleInput() throws IOException { if (Mouse.isCreated()) { while (Mouse.next()) { this.handleMouseInput(); } } if (Keyboard.isCreated()) { while (Keyboard.next()) { this.handleKeyboardInput(); } } } // Snip - don't need to include handleMouseInput... /** * Handles keyboard input. */ public void handleKeyboardInput() throws IOException { char c0 = Keyboard.getEventCharacter(); if (Keyboard.getEventKey() == 0 && c0 >= 32 || Keyboard.getEventKeyState()) { this.keyTyped(c0, Keyboard.getEventKey()); } this.mc.dispatchKeypresses(); }
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:
public void handleInput() throws IOException { if (Mouse.isCreated()) { while (Mouse.next()) { if (this != this.mc.currentScreen) { // Screen changed - bail out! return; } this.handleMouseInput(); } } if (Keyboard.isCreated()) { while (Keyboard.next()) { if (this != this.mc.currentScreen) { // Screen changed - bail out! return; } this.handleKeyboardInput(); } } }
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.
Environment
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)
Linked Issues
is duplicated by40
MC-30033Hopper: java.lang.IndexOutOfBoundsException: Index: 58, Size: 45DuplicateMC-30122Hopper: java.lang.IndexOutOfBoundsException: Index: 49, Size: 45DuplicateMC-30152Hopper: java.lang.IndexOutOfBoundsException: Index: 48, Size: 45DuplicateMC-30328Hopper: java.lang.IndexOutOfBoundsException: Index: 49, Size: 45DuplicateMC-31289Hopper: java.lang.IndexOutOfBoundsException: Index: 54, Size: 45DuplicateMC-31705Hopper: java.lang.IndexOutOfBoundsException: Index: 60, Size: 45DuplicateMC-31949Hopper: java.lang.IndexOutOfBoundsException: Index: 46, Size: 45DuplicateMC-31961Hopper: java.lang.IndexOutOfBoundsException: Index: 87, Size: 45DuplicateMC-32003Hopper: java.lang.IndexOutOfBoundsException: Index: 60, Size: 45DuplicateMC-32020Hopper: java.lang.IndexOutOfBoundsException: Index: 81, Size: 45DuplicateMC-32070Hopper: java.lang.IndexOutOfBoundsException: Index: 58, Size: 45DuplicateMC-32667Hopper: java.lang.IndexOutOfBoundsException: Index: 49, Size: 45DuplicateMC-32904Hopper: java.lang.IndexOutOfBoundsException: Index: 51, Size: 45DuplicateMC-33130Hopper: java.lang.IndexOutOfBoundsException: Index: 64, Size: 45DuplicateMC-35052Hopper: java.lang.IndexOutOfBoundsException: Index: 53, Size: 45DuplicateMC-35212Hopper: java.lang.IndexOutOfBoundsException: Index: 49, Size: 45DuplicateMC-35367Hopper: java.lang.IndexOutOfBoundsException: Index: 53, Size: 45DuplicateMC-36221Hopper: java.lang.IndexOutOfBoundsException: Index: 66, Size: 45DuplicateMC-36231Hopper: java.lang.IndexOutOfBoundsException: Index: 55, Size: 45DuplicateMC-37190Hopper: java.lang.IndexOutOfBoundsException: Index: 54, Size: 45DuplicateMC-37424Hopper: java.lang.IndexOutOfBoundsException: Index: 81, Size: 45DuplicateMC-37442Hopper: java.lang.IndexOutOfBoundsException: Index: 54, Size: 45DuplicateMC-37559Hopper: java.lang.IndexOutOfBoundsException: Index: 84, Size: 45DuplicateMC-37621Hopper: java.lang.IndexOutOfBoundsException: Index: 60, Size: 45DuplicateMC-37711Hopper: java.lang.IndexOutOfBoundsException: Index: 49, Size: 45DuplicateMC-37725Hopper: java.lang.IndexOutOfBoundsException: Index: 87, Size: 45DuplicateMC-37879Hopper: java.lang.IndexOutOfBoundsException: Index: 50, Size: 45DuplicateMC-41258game crash DuplicateMC-41524Hopper: java.lang.IndexOutOfBoundsException: Index: 85, Size: 45DuplicateMC-43294SMP - IndexOutOfBoundsException (Index: 48, Size: 45)DuplicateMC-43458Game is closedDuplicateMC-43762Updating screen eventsDuplicateMC-54639Updating screen eventsDuplicateMC-54685Minecraft crashed on closing a chest with E and accidentally pressing 2DuplicateMC-56223In a chest, holding ESC+1 while highlighting any hotbar slot crashes gameDuplicateMC-63851Game crashed while using hotkeys to craft a new pick.DuplicateMC-91455Hopper: java.lang.IndexOutOfBoundsException: Index: 55, Size: 45DuplicateMC-106400Crash when closing a chestDuplicateMC-112854Windows 10 resource starvation kills game engine with NULL pointer referenceDuplicateMC-116688Inventory crash the gameDuplicate
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
- Fixed
Frédéric Gierlinger- 9
- 10
- Confirmed
- Survival
- inventory null-pointer-exception
1.6.2 - 1.12.2
1.6.2 1.6.4 13w41b 1.7.1 1.7.2 13w48b 1.7.9 14w17a 14w21b 14w30c 14w34d 1.8-pre3 1.8 1.9 1.10.2 16w43a 16w44a 1.11-pre1 1.11 16w50a 1.11.1 1.11.2 17w06a 17w13a 17w13b 17w14a 17w15a 17w16a 17w17b 17w18a 17w18b 1.12-pre1 1.12-pre2 1.12-pre3 1.12-pre5 1.12-pre6 1.12-pre7 1.12 1.12.1-pre1 1.12.1 1.12.2-pre1 1.12.2-pre2 1.12.2- 17w43a
Created Issue:
NullPointerException on key press
Put the summary of the bug you're having here
What I expected to happen was...:
Nothing special, just rearranging my inventory.What actually happened was...:
Accidentally pressed "Drop item" (RShift) and suddenly the game crashed.Steps to Reproduce:
Could not reproduce bugEnvironment
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)
Minecraft: 1.6.2 (updated Tue Aug 06 13:00:00 CEST 2013)
is duplicated by
NullPointerException on key pressIndexOutOfBoundsException on key press
is duplicated by
is duplicated by
Put the summary of the bug you're having here
What I expected to happen was...:
Nothing special, just rearranging my inventory.What actually happened was...:
Accidentally pressed "Drop item" (RShift) and suddenly the game crashed.Steps to Reproduce:
Could not reproduce bugDescription: Updating screen eventsjava.lang.IndexOutOfBoundsException: Index: 57, Size: 45 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at ux.a(SourceFile:321) at bcz.a(SourceFile:295) at awv.a(SourceFile:582) at awv.a(SourceFile:597) at awb.n(SourceFile:149)
is duplicated by
is duplicated by
is duplicated by
is duplicated by
relates to
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
Put the summary of the bug you're having here
What I expected to happen was...:
Nothing special, just rearranging my inventory.What actually happened was...:
Accidentally pressed "Drop item" (RShift) and suddenly the game crashed.Steps to Reproduce:
From
Could not reproduce bugDescription: Updating screen eventsjava.lang.IndexOutOfBoundsException: Index: 57, Size: 45 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at ux.a(SourceFile:321) at bcz.a(SourceFile:295) at awv.a(SourceFile:582) at awv.a(SourceFile:597) at awb.n(SourceFile:149)
Put the summary of the bug you're having here
What I expected to happen was...:
Nothing special, just rearranging my inventory.What actually happened was...:
Accidentally pressed "Drop item" (RShift) and suddenly the game crashed.Steps to Reproduce:
From
Could not reproduce bugDescription: Updating screen eventsjava.lang.IndexOutOfBoundsException: Index: 57, Size: 45 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at ux.a(SourceFile:321) at bcz.a(SourceFile:295) at awv.a(SourceFile:582) at awv.a(SourceFile:597) at awb.n(SourceFile:149)Put the summary of the bug you're having here
What I expected to happen was...:
Nothing special, just rearranging my inventory.What actually happened was...:
Accidentally pressed "Drop item" (RShift) and suddenly the game crashed.Steps to Reproduce:
FromMC-54685:
I've since found that other key combinations also cause the crash. I have E set to inventory, F to drop, and 1–9 to the hotbar slots. The crash can be triggered by E + F as well as E + 1–9. It seems like it might depend on what's in the chest, perhaps whether or not there's something in the slot that the cursor is over. It's also quite sensitive to the timing of the keypresses; you might have to try a few times to reproduce.Description: Updating screen eventsjava.lang.IndexOutOfBoundsException: Index: 57, Size: 45 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at ux.a(SourceFile:321) at bcz.a(SourceFile:295) at awv.a(SourceFile:582) at awv.a(SourceFile:597) at awb.n(SourceFile:149)
is duplicated by
IndexOutOfBoundsException on key pressCrash on pressing the inventory close key and an item manipulation key at the same time
is duplicated by
is duplicated by
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)
Minecraft: 1.6.2 (updated Tue Aug 06 13:00:00 CEST 2013)
![[Mod] Skylinerw](../../../data/assets/gravatar/skylinerw.png){kind=small}
is duplicated by
Put the summary of the bug you're having here
What I expected to happen was...:
Nothing special, just rearranging my inventory.What actually happened was...:
Accidentally pressed "Drop item" (RShift) and suddenly the game crashed.Steps to Reproduce:
FromMC-54685:
I've since found that other key combinations also cause the crash. I have E set to inventory, F to drop, and 1–9 to the hotbar slots. The crash can be triggered by E + F as well as E + 1–9. It seems like it might depend on what's in the chest, perhaps whether or not there's something in the slot that the cursor is over. It's also quite sensitive to the timing of the keypresses; you might have to try a few times to reproduce.Description: Updating screen eventsjava.lang.IndexOutOfBoundsException: Index: 57, Size: 45 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at ux.a(SourceFile:321) at bcz.a(SourceFile:295) at awv.a(SourceFile:582) at awv.a(SourceFile:597) at awb.n(SourceFile:149)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 [Mod] Pokechu22.
To reproduce
- 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)
Speculations on the cause
I think this specific part of the crash report explains what's happening pretty well:
-- Affected screen -- Details: Screen name: ~~ERROR~~ NullPointerException: nullNote also the message of the exception:
java.lang.IndexOutOfBoundsException: Index: 53, Size: 46Specifically, 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...
Which slots cause crashes, exactly?
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.
Code analysis
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:
protected void keyTyped(char typedChar, int keyCode) throws IOException { System.out.println("Key '" + typedChar + "' typed in " + this + " - active is " + this.mc.currentScreen + " (same = " + (this.mc.currentScreen == this) + ")"); // Regular code... if (keyCode == 1 || keyCode == this.mc.gameSettings.keyBindInventory.getKeyCode()) { this.mc.thePlayer.closeScreen(); } this.checkHotbarKeys(keyCode); if (this.theSlot != null && this.theSlot.getHasStack()) { if (keyCode == this.mc.gameSettings.keyBindPickBlock.getKeyCode()) { this.handleMouseClick(this.theSlot, this.theSlot.slotNumber, 0, ClickType.CLONE); } else if (keyCode == this.mc.gameSettings.keyBindDrop.getKeyCode()) { this.handleMouseClick(this.theSlot, this.theSlot.slotNumber, isCtrlKeyDown() ? 1 : 0, ClickType.THROW); } } }Normally (when the '1' is processed before the 'e', you'd get this:
Key '1' typed in net.minecraft.client.gui.inventory.GuiChest@77f36fa7 - active is net.minecraft.client.gui.inventory.GuiChest@77f36fa7 (same = true) Key 'e' typed in net.minecraft.client.gui.inventory.GuiChest@77f36fa7 - active is net.minecraft.client.gui.inventory.GuiChest@77f36fa7 (same = true)But when the game crashes, you get this:
Key 'e' typed in net.minecraft.client.gui.inventory.GuiChest@685af84b - active is net.minecraft.client.gui.inventory.GuiChest@685af84b (same = true) Key '1' typed in net.minecraft.client.gui.inventory.GuiChest@685af84b - active is null (same = false)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:
/** * Delegates mouse and keyboard input. */ public void handleInput() throws IOException { if (Mouse.isCreated()) { while (Mouse.next()) { this.handleMouseInput(); } } if (Keyboard.isCreated()) { while (Keyboard.next()) { this.handleKeyboardInput(); } } } // Snip - don't need to include handleMouseInput... /** * Handles keyboard input. */ public void handleKeyboardInput() throws IOException { char c0 = Keyboard.getEventCharacter(); if (Keyboard.getEventKey() == 0 && c0 >= 32 || Keyboard.getEventKeyState()) { this.keyTyped(c0, Keyboard.getEventKey()); } this.mc.dispatchKeypresses(); }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:
public void handleInput() throws IOException { if (Mouse.isCreated()) { while (Mouse.next()) { if (this != this.mc.currentScreen) { // Screen changed - bail out! return; } this.handleMouseInput(); } } if (Keyboard.isCreated()) { while (Keyboard.next()) { if (this != this.mc.currentScreen) { // Screen changed - bail out! return; } this.handleKeyboardInput(); } } }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.
Crash on pressing the inventory close key and an item manipulation key at the same time in large chests
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
is duplicated by
is duplicated by
relates to
Not seeing any recent report of this issue, so assuming fixed.
MC-31222 may be related.
Duplicate of Unresolved
MC-31222
If you have not, please use the search function in the future, to see if your bug has already been submitted. If you could not find the original report, please comment with the keywords you searched for.
This error is similar to MC-31222, however before I even join a server.
Reproduction:
1.Make sure a lan server is running, preferrably by another account and computer.
2.Press the Multiplayer Option
3.Click on the lan server as it appears at the bottom of the list.
4.Hold shift and press the "up" button.
5. (Ocassionally) If this doesn't work try selecting another server or something.
At this stage the launcher should be frozen for a bit and then reopen with crash reporter.
This is as current 1.7.10 and 1.8-pre3.
The below attachment (named raw, not crashreport) is originally from pastebin: http://pastebin.com/raw.php?i=szJCw7D0
The second attachment (crash report.txt) is the 1.8 crash.
---- Minecraft Crash Report ---- // My bad. Time: 31/08/14 7:02 PM Description: Updating screen events java.lang.IndexOutOfBoundsException: Index: 1, Size: 1 at java.util.ArrayList.rangeCheck(Unknown Source) at java.util.ArrayList.get(Unknown Source) at bge.b(SourceFile:35) at bfz.b(SourceFile:324) at bfz.a(SourceFile:253) at bdw.l(SourceFile:245) at bdw.p(SourceFile:217) at bao.p(SourceFile:1328) at bao.ak(SourceFile:774) at bao.f(SourceFile:728) at net.minecraft.client.main.Main.main(SourceFile:148) A detailed walkthrough of the error, its code path and all known details is as follows: --------------------------------------------------------------------------------------- -- Head -- Stacktrace: at java.util.ArrayList.rangeCheck(Unknown Source) at java.util.ArrayList.get(Unknown Source) at bge.b(SourceFile:35) at bfz.b(SourceFile:324) at bfz.a(SourceFile:253) at bdw.l(SourceFile:245) at bdw.p(SourceFile:217) -- Affected screen -- Details: Screen name: bfz Stacktrace: at bao.p(SourceFile:1328) at bao.ak(SourceFile:774) at bao.f(SourceFile:728) at net.minecraft.client.main.Main.main(SourceFile:148) -- System Details -- Details: Minecraft Version: 1.7.10 Operating System: Windows 7 (x86) version 6.1 Java Version: 1.7.0_67, Oracle Corporation Java VM Version: Java HotSpot(TM) Client VM (mixed mode), Oracle Corporation Memory: 74257616 bytes (70 MB) / 167923712 bytes (160 MB) up to 523501568 bytes (499 MB) JVM Flags: 6 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx512M -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:-UseAdaptiveSizePolicy -Xmn128M AABB Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0 Launched Version: 1.7.10 LWJGL: 2.9.1 OpenGL: Intel(R) HD Graphics GL version 2.1.0 - Build 8.15.10.2119, Intel GL Caps: Using GL 1.3 multitexturing. Using framebuffer objects because EXT_framebuffer_object is supported. Anisotropic filtering is supported and maximum anisotropy is 2. Shaders are available because OpenGL 2.1 is supported. Is Modded: Probably not. Jar signature remains and client brand is untouched. Type: Client (map_client.txt) Resource Packs: [] Current Language: English (UK) Profiler Position: N/A (disabled) Vec3 Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used Anisotropic Filtering: Off (1)
Dupe of MC-31222
Very likely duplicates MC-31222
Looks like MC-31222
Incomplete without crash report (minecraft/crash-reports/crash-<DATE>-client.txt). Please attach it so that we can diagnose your issue.
Crash report
This has happened twice to me now, both times while viewing a chest. Cannot reliably reproduce.
I found it pretty easy to reproduce. Check out my report (
MC-54685, listed as a duplicate here) for details.Edit: OP's edited it in.
I can confirm this.
Oh, hey, so that's why I crashed! I was just trying to make a new pick, and my game crashed. Happened in a crafting table. Only, for me, the pick and the items used to craft it were completely gone when I logged back in to the world. Like the opposite of a dupe bug.
Cannot reproduce: 14w33a
I have been receiving this error, however before I even join a server.
I can supply a crash report as well (already published it).
Reproduction:
1.Make sure a lan server is running, preferrably by another account and computer.
2.Press the Multiplayer Option
3.Click on the lan server as it appears at the bottom of the list.
4.Hold shift and press the "up" button.
5. (Ocassionally) If this doesn't work try selecting another server or something.
At this stage the launcher should be frozen for a bit and then reopen with crash reporter.
This is as current 1.7.10 , I shall try with the latest snapshot and see how it goes.
Edit:
This still occurs in 1.8-pre3.
Should I make a new report, if this is a different cause to the same error?
Can you pastebin the crash report?
Ok, try this:
http://pastebin.com/raw.php?i=szJCw7D0
I think that is a slightly different issue.
Ok, i Have now made a new issue to cover this.
MC-70845For me on 1.8 it visually deletes/duplicates the item in the selected hotbar, but it doesn't crash and opening a inventory screen fixes the issue.
Is this still an issue in the most recent versions (currently that is 1.10.2, or 16w42a) of Minecraft? If so, please update the affected versions and help us keeping this ticket updated from time to time. If you are the owner/reporter of this ticket, you can modify the affected version(s) yourself.
Confirmed on latest snapshot, and added a code analysis.
Due to the way LWJGL 3 works, the suggested fix is present in the new code (as far as I can tell); keyboard events aren't being passed to closed GUIs anymore.