[MCL-1] Unable to update minecraft: Fatal error occured (4): null

Started it up, coming from the 1.4.1 pre-release I think, but it never gets past the launcher anyway:

$ ./minecraft
java.lang.NullPointerException
at net.minecraft.GameUpdater.downloadJars(GameUpdater.java:520)
at net.minecraft.GameUpdater.run(GameUpdater.java:286)
at net.minecraft.Launcher$1.run(Launcher.java:84)
Fatal error occured (4): null
java.lang.NullPointerException
at net.minecraft.GameUpdater.downloadJars(GameUpdater.java:520)
at net.minecraft.GameUpdater.run(GameUpdater.java:286)
at net.minecraft.Launcher$1.run(Launcher.java:84)

Linked issues

is duplicated by 13

MCL-4 Launcher "fatal error 4 (null)" error - fix included Resolved

MCL-265 Failed to Launch: Fatal Error occurred (4) Resolved

MCL-266 error: Fatal error (4): null Resolved

MCL-267 "failed to launch fatal error occurred (4)" and then shows a missing directory for the minecraft.jar file. Resolved

MCL-268 failed to launch Resolved

8 more links

Comments 19

migrated 2012-10-25T13:04:35Z

This is an error specific to your install and not a bug. Try deleting your .bin folder and forcing an update. That should fix the problem.

migrated 2012-10-25T13:06:29Z

cd ~/.minecraft
mv bin bin-old

Same error 😞 ---- Oh wait, I forgot to say force update. (but I don't think that'll fix it)

migrated 2012-10-25T13:08:48Z

Nope it didn't.

$ ls ~/.minecraft/bin
md5s  version

migrated 2012-10-25T13:24:57Z

Here's a quick screen capture of me trying to launch:

http://www.youtube.com/watch?v=S05hQgWITek

for additional reference

$ java -version
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)

migrated 2012-10-25T15:23:56Z

@Ezekiel Elin:

There is no "Library" directory in my home folder, I don't think that will solve anything.

9 more comments

Ezekiel 2012-10-25T16:07:31Z

@David Delete your minecraft folder or move it to another location. Then try.

migrated 2012-10-25T16:58:36Z

Sadly, none of that works:

$ mv ~/.minecraft ~/.minecraft-old
$ cd MyStuff/
$ ./minecraft
asdf
java.io.FileNotFoundException: /home/dkowis/.minecraft/lastlogin (No such file or directory)
	at java.io.FileInputStream.open(Native Method)
	at java.io.FileInputStream.<init>(FileInputStream.java:138)
	at net.minecraft.LoginForm.readUsername(LoginForm.java:110)
	at net.minecraft.LoginForm.<init>(LoginForm.java:55)
	at net.minecraft.LauncherFrame.<init>(LauncherFrame.java:23)
	at net.minecraft.LauncherFrame.main(LauncherFrame.java:167)
java.lang.NullPointerException
	at net.minecraft.GameUpdater.downloadJars(GameUpdater.java:454)
	at net.minecraft.GameUpdater.run(GameUpdater.java:247)
	at net.minecraft.Launcher$1.run(Launcher.java:76)
Fatal error occured (4): null
java.lang.NullPointerException
	at net.minecraft.GameUpdater.downloadJars(GameUpdater.java:454)
	at net.minecraft.GameUpdater.run(GameUpdater.java:247)
	at net.minecraft.Launcher$1.run(Launcher.java:76)

migrated 2012-10-25T17:03:07Z

It seems to work just fine at home, so I'm going to say that this is an isolated network issue that's happening at my current location 😞

I'll leave it up to the mojang devs if they want to have a nicer error than (4) null

migrated 2012-10-25T20:24:59Z

This was a support request. Not a bug.

migrated 2012-11-22T16:50:54Z

There is indeed a bug in the launcher, as a quick decompile of the launcher JAR shows. See this code around line 454 of GameUpdater, in the downloadJars() method:

str1 = localURLConnection.getHeaderField("ETag");
str1 = str1.substring(1, str1.length() - 1);

The code blindly assumes that the HTTP response header always contains an ETag field, which is not necessarily true. This tag is often stripped by HTTP proxies.

Very easily fixed by adding a "if (str1 != null)" test to line 454 (note that str1 is later compared with null in the method so it's to continue with it set to null).

migrated 2012-11-22T21:11:02Z

I was pretty confident a null pointer exception isn't a support request.

Erik Broes 2012-12-10T10:20:38Z

The code is not using any proxies, if you are routing all of your traffic through proxies that mangle the data that comes back and thus violating tons of standards there is absolutely nothing we should do to support that.

migrated 2012-12-10T15:20:22Z

18 days later and this is it?! This is not resolved.

It's very clear that your code isn't using any proxies. It's just blindly assuming that an ETag header is present in one part of downloadJars() (and thus throwing an NPE if it isn't), even though it later tests for it. So it's internally inconsistent for a start.

Any in any case, can you name which standard, exactly, is violated by a proxy stripping an ETag header? I'll ignore the hyperbolic use of "tons of standards", I'd just like one standard, please. Don't bother mentioning RFC 2068; although it states that a proxy MUST NOT modify ETag headers, it says nothing about removing them.

Finally: even if this were a standards violation, users behind such proxies often don't make a conscious decision to use them. Are you going to penalise them in such a petty fashion just for having a computer in the wrong place? All it takes to fix the problem is a simple one-line null comparison (which, as I said, you do anyway a few lines further down in the method).

kumasasa 2012-12-11T21:32:21Z

The (more up to date) RFC 2616 writes in Section 13.5.2

A transparent proxy MUST NOT modify any of the following fields in a
request or response, and it MUST NOT add any of these fields if not
already present:
Content-Location
Content-MD5
ETag
Last-Modified

Even it's not explicit mentioned that a removal of the headers is forbidden, it is quite clear from the context that a proxy must not do anything with those headers, neither modify nor add nor remove.

Nevertheless following the basic rule of internet programming "Be strict when sending and be relaxed when receiving" the really marginal fix to the launcher would improve the stability...

migrated 2012-12-12T10:27:14Z

I disagree that it's clear that proxies must not remove these headers. It explicitly states that they must not be modified or added. Think about it for a minute: an ETag is effectively a checksum on the resource being requested/sent. It's very bad if a proxy adds or changes an ETag that the client already has cached, since this could result in an updated file not getting pulled when it should be. But if there's no ETag at all, the worst result is that a new file is sent when not strictly required, since the client doesn't have any cached ETag to check with the server. Extra use of network bandwidth, yes, but the data transferred remains valid.

The RFC does not state that ETag headers must not be removed. That text you quoted also specifically refers to transparent proxies, which does not include application-layer proxies that the client explicitly connects to. Transparent proxies rewrite requests at the network layer, and the client has no way of knowing that such a proxy is even present. (When I tested, I was using an application layer proxy by passing command-line options to the JVM).

But in any case, I'm glad you agree that the fix is trivial. And since you check for the presence of ETag headers later in the very same method anyway, it's clear that someone at some point wrote the code to correctly handle the case where an ETag is not provided. So you will lose nothing by fixing this problem, and gain a few more satisfied users. It really is a no-brainer.

migrated 2013-01-02T20:21:28Z

It would be really nice if this were fixed, however. I'm behind some sort of evil proxy magic that I have no control over. There's nothing I can do about it, and so I cannot update minecraft due to a very ugly looking "Error: null"

migrated 2013-04-24T19:55:35Z

This is resolved with the new Dev Launcher. The old launcher still borks.

migrated 2013-05-13T00:58:42Z

so how can I fix this...i am just regular mom trying to understand this.....any easy way of explaining it?

kumasasa 2013-05-13T05:48:51Z

@Logan Jacobs: Either wait until 1.6 is out or get the new launcher from here: http://mojang.com/2013/05/minecraft-snapshot-13w19a/ - you can play the current version 1.5.2 as well the new snapshots 13wXXy with the new launcher. The files install besides the "old launcher files" so there is no interference.