[1.6.2] (decompile fail) install.sh won't patch "temp.patch" and recompile

[Iree]

I am sure I am doing something common and stupid.

Can someone please take a look at the log?

 

http://pastebin.com/GthuNmsN

 

I tried with this forge, latest forge and recommended forge.

I tried with scala installed and without.

Running install though mod-to-be-compiled's build script and directly

Nothing changed.

 

Thanks

[Iree]

UPDATE: I tried looking for the reason why those patches did not apply.

This is a result for searching "case 167" though the entire tree: http://pastebin.com/vQ9bUpL7

My decompiled FontRenderer.java actually has no "case" in it.

It has "if(p_78263_1_ == 167) {" instead

 

Obviously the decompile step ended with different code than expected.  Any clue why could that be?

 

PS: Do you think it could be "solved" by asking someone else to send me an installed forge directory?

 

 

UPDATE2: I tried looking at the first compile error.

It says this file is missing the return statement:  http://pastebin.com/8Pff07NV

Obviously it's missing way more than that.

 

It's now clear that the decompilation is failing horribly.

[Iree]

Update: I obtained a copy of already-installed forge sources.

I was able to successfully compile and run Project:Red mod using those.

 

I assume it means that java/jdk/jre/java compiler/python/ant are working properly.

Which means that all those .jar tools shipped with forge should also be OK.

 

Can you please hint me which piece of software on my machine could be causing such issues?

A piece that is used only during decompilation?

 

[LexManos]

This can happen sometimes when fernflower has an error decompiling a function.

It'll just return a empty function.

Typically that is a out of memory error.

If you go into the mcp/conf/mcp.cfg file

And find the Decompile Cmd entry and up the amount of ram it's given.

[Iree]

Thanks a lot for the reply.

 

Is that CmdFernflower?

I managed to get 966M of RAM available for the build.

 

Question: Can I change mcp.cfg in a way that will preserve the change when I run install.py?

Answer: Edit  fml/config/mcp.cfg instead!

 

Trying with 768M for fernflower..  No change while patching.  55 build errors as always.

 

Now I noticed that some of the commands are set with -Xmx 1024M, which is not available.

I tried reducing those to 900M.. No change while patching.  55 build errors as always.

 

Trying with 900M for fernflower..  No change while patching. 55 build errors as always.

 

I have almost doubled fernflower's memory and still not even a tiny change.

What else could be failing? (I suspect something not written in java)

 

PS:

I wonder why it has only -Xmx and not -Xms or -Xincgc.

(Answer: It made "Really Applying SpecialSource" fail. No idea why)

And I also wonder why is fernflower by default limited to 512M while other commands are limited to 1G.

 

I'll try with  1400M for fernflower (using ~512M of SWAP) over the night, but I don't really expect any changes.

 

PPS:

I almost forgot to tell you my friend (who owns that linux machine) says it's special ("non-x86", whatever that means)

I thought java runs the same way everywhere, so i didn't really care.

Does that explain anything?

[LexManos]

java should run the same anywhere, except when interacting with native code.

But there are JVMs out there that fuck things up.

Best I can say is if you don't have enough ram to finish the deocmpile, then you have to find a computer that does.

The mcp/logs folder should have the complete FernFlower decompile log. Check that for more information.

[Iree]

I gave it 2 extra gigabytes of swap space and gave fernflower 2048M

I also gave the same amount of RAM to the other mem-limited commands in the file.

I tried looking at memory usage during decompilation.. it seems that fernflower was using around 200M

Nothing has changed (The same patches didn't apply. The same compile errors.)

I guess it cannot be the RAM space, then?

 

I am using OpenJDK-7, which is reported to work fine.

 

Adding of SWAP should make it just extra slow, but working, right?

 

I found the fernflower output in mcp.log. It has a lot of errors. No clue why.

I had to remove "time" from the lines so it would fit on pastebin.

http://pastebin.com/uLMbT93F

 

If anything, I would really like to figure out which program is failing and report the issue to ubuntu.

 

 

[LexManos]

Interesting, it's not telling us exactly whats erroring. I haven't seen it fail that hard at decompiling. Something is causing your computer to fail hard.

Typically its a ram issue if it's one or two functions. But the fact that you're erroring in a lot .. i'm not quite sure.

 

It'd be java, something inside Foernflower.

Can you get  me a full console log of you running the install?

[Iree]

Additionally the fails appear to be still the same. I doubt bad RAM would be able to do that.

 

Sure. Running the install means "python install.py" ?

I got that in the paste in the first post of this thread.

Ignore first 11 and last  6 lines, those are made by the script that executed "python install.py"

 

You have my word that the output will be the same when I run it directly with current forge.

Shall I do it anyway?

[LexManos]

Can you get me the log manually?

Ant loves to fuck over and jumble the output i dont know why.

[Iree]

Sure

Here you go: http://pastebin.com/3NtKf79c

 

Unzipped forge 849 src

ran install.py for a while to get mcp downloaded, aborted

put mcp/jars I already had from previous attempts (files.mcf.net was rather slow recently, not loading it more)

python install.py --no-assets 2>&1 | tee forgeinstall.log

 

I am not sure there is any useful information in that file.

But I hope it'll help push things closer to figuring what is wrong and where.

[Iree]

Is there anything I can do to help report the issue to the correct place?

 

PS:

I noticed that java --version says "OpenJDK Zero VM"

Instead of "OpenJDK 64-Bit Server VM" other people said it says for them.

 

But I installed  openjdk-7-jdk, the same package as them.

No idea why has ubuntu put a Zero VM instead of the Server VM in it.