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)
Environment
Linux 64-bit
Linked Issues
is duplicated by13
Created Issue:
Unable to update minecraft
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)Environment
Linux 64-bit
Linked Issues
is duplicated by9
mv ~/Library/Application\ Support/minecraft ~/DesktopThen run minecraft.
is duplicated by
Unable to update minecraftUnable to update minecraft: Fatal error occured (4): null
is duplicated by
is duplicated by
is duplicated by
is duplicated by
See also MC-431, which was wrongly closed as "not a bug".
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 safe to continue with it set to null).
Duplicate of MCL-1, please use the search function to see if your bug has already been submitted.
Duplicate of MCL-1, please use the search function to see if your bug has already been submitted.
You've reported on the wrong project, go to this link to write your launcher problem (I had enough with this) MCL-1
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.
cd ~/.minecraft
mv bin bin-old
<launch minecraft via the launcher jar again>
Same error
---- Oh wait, I forgot to say force update. (but I don't think that'll fix it)
Nope it didn't.
Here's a quick screen capture of me trying to launch:
http://www.youtube.com/watch?v=S05hQgWITek
for additional reference
@Ezekiel Elin:
There is no "Library" directory in my home folder, I don't think that will solve anything.
@David Delete your minecraft folder or move it to another location. Then try.
Sadly, none of that works:
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
This was a support request. Not a bug.
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).
I was pretty confident a null pointer exception isn't a support request.
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.
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).
The (more up to date) RFC 2616 writes in Section 13.5.2
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...
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.
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"
This is resolved with the new Dev Launcher. The old launcher still borks.
so how can I fix this...i am just regular mom trying to understand this.....any easy way of explaining it?
@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.