[MC-3409] Single player mode, creative mode, E to select block, select block from grid, E to return to game, game freezess, crash log created

Single player mode > creative mode > E to select block > select block from grid > E to return to game > game freezes > crash log created.

Linked issues

is duplicated by 30

MC-3414 Minecraft crashes when leaving creative inventory, version 1.4.4 Resolved

MC-4319 Crashing I feel sad now :( Description: Updating screen events java.lang Resolved

MC-4766 crashes when you push the e button Resolved

MC-4856 Hello. We are on a Mac OS X 10.6.8. We have our Game Crash everytime we exit Inventory. We changed the button to exit, it still crashes. Any Help would be appreciated. Resolved

MC-4999 CRASH: Description: Updating screen events [happens repeatably when pressing E button] Resolved

25 more links

Attachments

crash-2012-11-18_09.08.59-client.txt

Comments 19

kumasasa 2012-12-09T22:02:51Z

Note:

Description: Updating screen events
java.lang.IndexOutOfBoundsException: -100
	at java.nio.DirectByteBuffer.get(Unknown Source)
	at org.lwjgl.input.Keyboard.isKeyDown(Keyboard.java:399)
	at avl.a(SourceFile:266)

Georgia Yancey 2012-12-27T19:42:47Z

Why is there no fix for this issue? We have the same problem and I see it was first posted in November.

John Dotson 2012-12-30T03:16:40Z

Agree with Georgia, why isn't there a fix. My sons spent some of their Christmas money to get this broken program.

Andreas 2012-12-30T03:43:12Z

I am not sure if anyone receives this but I tried to use the app under a different user and it does NOT crash. So on my MAC it was a permission issue. Ensure your user account you are logged on is administrator, has full read and write access and no parent control is set up or enabled.

This worked for me. Hope it works for all of you out there.

(somehow I don't think this is the fix though as I woul emagine the guys at minecraft would have tested that one)

John Dotson 2012-12-30T21:22:12Z

Logged onto pc as a different user?

9 more comments

Andreas 2012-12-31T03:30:12Z

Yes. But a Mac. OS X. Make sure you are logged on to the operating system (Mac or Pc) with administrator privilege. I think it has to do with permission. It worked for us. It has not crashed once. But please this might have just been the case for us and yours still crashes. Hope it works for you

Heather McBride 2013-01-04T03:14:31Z

I have logged into the account on 3 different computers and all have this issue. all three have administrator rights to the logged in user. is there any other fix to this issue?

Andreas 2013-01-04T04:38:12Z

Do you have a firewall enabled?
I had parenting controll enabled, once disabled and with full admin rights it worked for me.
I also googled this error and had a few links (which I did NOT need to check as the first thing the link asked to enable admin rights)

Sorry it does not work for you

John Dotson 2013-01-07T02:39:02Z

I change my firewall rules to allow Minecraft, and changed the program to run as Administrator (even though the only user account on the Win7 box is Adminstrator) to no avail. I then uninstalled and reinstalled Minecraft and the issue has disappeared. I am concerned as I did see a comment somewhere about having a 32bit version of Java instead of a 64bit, but can't find it again and couldn't do anything about it on my 32bit box anyway. Thanks to all who have commented here to help give me ideas to remediate.

Andreas 2013-01-07T03:34:12Z

Well done John
Ok, mental note of re-installing the application once the firewall is removed.
I did no have to do this but it should go on record...

Michael Keller 2013-01-19T21:19:50Z

None of these solutions has worked for me. How long does it typically take Mojang to issue an official fix for something that is so severly impacting so many end-users? I am new to their world. Thanks.

Tails 2013-01-19T21:24:23Z

I suggest voting for this issue to get more attention to it.

Andreas 2013-01-19T22:35:48Z

Same with us.
It's a read/write issue. Once I assigned administrator rights the problem was resolved

Good luck to all.

bugi74 2013-02-07T19:34:25Z

Reproducible, debugged, and crude fix found (and yet another thing to check for those with the problem).

Check
Ensure that the key configured for 'chat' is a keyboard key, not any mouse button.

Background
I was able to reproduce this crash (not 100% certainly the same reason, though) on win7 64-bit, java 7, MC 1.4.7. Normally I do not experience any of the described problems, but if I adjust my controls certain way, I can cause that crash (i.e. same stacktrace end).

The crash report reveals index out of bounds with value -100, and it is aimed at isKeyDown() method. Searching through the bulk of minecraft code revealed only one location that calls the method with anything else than hardcoded positive value: GuiContainerCreative.keyTyped(), which checks if the key bound to chat has been pressed.

Reproducing it
If that 'chat' key is (accidentally?) bound to mouse buttons (which are handled as key's with codes -100 etc.), then everything works upto opening inventory in creative... but there the next key press will hit this issue (unless already in the search tab) and the code asks LWJGL if the key with code -100 (for left mouse button for example) is down. LWJGL naturally knows nothing about negative key codes and hasn't protected itself from such "malicious" queries...

Fix

GuiContainerCreative.keyTyped(char, int)

if (selectedTabIndex != CreativeTabs.tabAllSearch.getTabIndex()) {
            if (this.mc.gameSettings.keyBindChat.keyCode >= 0 &&   /* <-- ADDED */
                    Keyboard.isKeyDown(this.mc.gameSettings.keyBindChat.keyCode)) {
                ...

Tested on 1.4.7 and after that change, the inventory can be closed even if the chat is bound in a mouse button.

Andreas 2013-02-08T00:27:44Z

Well, We can't say you did not spend any time on this...

Well done. Thanks.

Andreas

Regards,

Andreas Niederegger

GrygrFlzr 2013-02-08T00:38:12Z

Andreas: Don't spread your personal information over the internet, I removed it from your comment.

bugi74 2013-02-28T18:54:50Z

Affects 13w09b.

Sir TLUL 2013-02-28T19:13:16Z

Wouldn't the better fix be to pipe all isDown queries through a decoder method that handles -100, etc as the correct mouse buttons? This would also mean future input methods could be more easily integrated with legacy code. This isn't a frequently-called method (relatively speaking) so it would add very little overhead.

bugi74 2013-02-28T19:17:12Z

Yes, that would indeed better fix. Alas, the changes would be all over the place, so not feasible to include the code for a fix here. I'd apply that fix shown above for now, and add a Mojang-internal task to "do things right" with better time.