This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
LDDestroier's profile picture

My PUE API -- using paintutils.flipX will hang, then shutdown with "Java heap space"

Started by LDDestroier, 08 December 2017 - 01:47 PM
LDDestroier #1
Posted 08 December 2017 - 02:47 PM
I was trying to make a bunch of new functions for paintutils. One of them was flipX and flipY. However, for reasons that escape me, flipX gives me a cryptic error instead of working.

Expected result: returns the image, but flipped horizontally

Result: Computer hangs, then errors with "Java heap space".


I cannot figure out what "Java heap space" means, but looking at other peoples' reports of it makes it seem like Java is running out of memory. I could be wrong, though.

The demo (weLUU423) will make use of flipX, and will crash once the picture tries to flip. It will also automatically download PUE (7XAmsAbX) and use it. Help meee…
supernicejohn #2
Posted 08 December 2017 - 09:14 PM
On emulator both functions work, what setup are you using? Can't test MC version, but on CCEmuRedux with CC 1.7 it works well with both functions of flipX. (if 'i' in the "for x = 1, sizeX do" loop is changed to 'x' in the commented out one!)
Purple #3
Posted 08 December 2017 - 11:18 PM
Can you give us the whole text of the error? Like if it's big just make a screenshot of the thing.
Java heap space is definitively a java memory error though. So I am also going to ask how much memory your computer has. Also, what image are you using?
Edited on 08 December 2017 - 10:19 PM
Bomb Bloke #4
Posted 09 December 2017 - 03:02 AM
Tried a couple of different CC installs, could not reproduce. Need more details about your testing environment.
LDDestroier #5
Posted 09 December 2017 - 04:17 AM
Tried a couple of different CC installs, could not reproduce. Need more details about your testing environment.

I should have mentioned earlier, but it's fixed using the normal picture. However, with this picture on a big monitor, it crashes on its second attempt of flipping horizontally.

Can you give us the whole text of the error? Like if it's big just make a screenshot of the thing.
Java heap space is definitively a java memory error though. So I am also going to ask how much memory your computer has. Also, what image are you using?
There was no text in the error beyond "Java heap space". No line number, no nothing. However, I fixed the problem (the problem lied with centerWithBlankSpace methinks. I can't remember what ). Now it crashes when loading that trogdor image on a large monitor when flipping twice! I cannot recall if that too was a "Java heap space" error, but I don't think there was. It might just be a "too long without yield" error now.


I should probably hold off a little longer before asking help on the forum for the time being. Might be a learning experience to solve my own confounding errors. Thanks anyway.
Luca_S #6
Posted 09 December 2017 - 05:55 AM
In case anyone else is searching for a solution to their problem:

I don't know this much about LuaJ, but I would guess that the variables of a Lua program are stored in a Java Object, meaning on the Java Heap.

If you are using real MC try adding the "-Xmx4G" (You should adjust the number based on your RAM) flag to your minecraft. If you are using an Emulator try running it with this option.
However after all it means your programs is just using way too much RAM.
Purple #7
Posted 09 December 2017 - 06:55 PM
Huge images will do that.
Lupus590 #8
Posted 09 December 2017 - 09:05 PM
Could you use a the file system to create temperary buffers to reduce your memory usage?
SquidDev #9
Posted 09 December 2017 - 09:27 PM
Did some debugging with LDDestroyer: there was an infinite loop filling a table with numbers - I believe they've fixed that and everything now works.

On a more general note, there should never be a time where you're using so much memory that you run out. Even if you load every file from a computer into memory, you're still going to be using 1MB at most - that's nothing compared with the default allocation to a normal mod pack, If you do run out of memory, the answer isn't to allocate more - it's to start finding where the bug is.
Edited on 09 December 2017 - 08:28 PM
CLNinja #10
Posted 09 December 2017 - 10:04 PM
Did some debugging with LDDestroyer: there was an infinite loop filling a table with numbers - I believe they've fixed that and everything now works.

On a more general note, there should never be a time where you're using so much memory that you run out. Even if you load every file from a computer into memory, you're still going to be using 1MB at most - that's nothing compared with the default allocation to a normal mod pack, If you do run out of memory, the answer isn't to allocate more - it's to start finding where the bug is.

And i think Luca_S hit on that when talking about the -xm argument.

"However after all it means your programs is just using way too much RAM."
Bomb Bloke #11
Posted 10 December 2017 - 12:58 AM
Even if you load every file from a computer into memory, you're still going to be using 1MB at most

If you loaded all that data into a single string, sure, you'd cap out at about a meg. In practise, by the time that data's spread across a ton of different variables / keys / whatever, you'll typically be using a heck of a lot more than that. As you well know. :P/>/>/>

That said, you're correct in saying we should never run out of memory. I've unpacked and rendered individual GIF animations that were initially megabytes in size, for example. I've always wondered how my code would fare under OpenComputers - I think the most memory a system can have there is something like 7mb? That'd be way too restrictive for my tastes.

… though I did initially write my GIF unpacking stuff in QuickBASIC, many years ago. I had less than 640kb to play with, could only make arrays of up to 16kb, and I had no idea what a hashmap was. The result wasn't very fast.
Edited on 10 December 2017 - 12:23 AM
LDDestroier #12
Posted 12 December 2017 - 03:58 PM
I fixed the issue. It laid within prefixTbl and centerWithBlankSpace. Thanks for the help, I guess. Please close.