Some tips on the OOM client crash

[martinuzz]

Here's some notions about the annoying out of memory crashes that I, and many others are plagued by. I think it's only Enders, but maybe vanilla has them too. I never could stand to run that long enough to see if it crashes.

Some observations:
- every single object has a memory leak. Some objects leak more than others (cotton fields, windmill animation).
- shadows count as object for this purpose too.
- loading a new map (by entering /exiting a building or teleport) does not clear the memory leak, it keeps accumulating. Since a new busy map will give it rather large shot of new objects to leak from, a lot of crashes seem to appear after a reload.
- Those spots on the map that will cause your minimap to update when crossing them are also notorious for pushing you over the OOM edge.

Tips to minimize crashing:
- downgrade from Java7 to Java6. I heard from some people, that this doesn't work anymore, and I am too stubborn myself to 'downgrade', but it might be worth a try for you.
- turn off shadows. Reduce crashes to half.
- don't build (many) windmills
- minimize cotton planting, or make a separate base just for planting cotton, so it doesn't lag your main base.

Most annoying crashes
1) crash in PvP, lose your char.
2) crash while walking in between a gate. Makes you drop all your stuff, and most of that will drop under the gate / walls and be unretrievable
3) crash in a canoe or a boat. About 50% of the time, you will not be able to log back into where you crashed, causing you to lose your inventory to the water, and having to find your boat back, starting from your bind.
4) crash in a canoe / boat, while carrying a boat. Boat will despawn, and be lost forever.
5) crash while being aggro'd by argopelter. Unless you have really high biles and log back in real quick, you're at the mercy of the argopelter, and anyone stumbling upon your argo-locked comateuse avatar.

How to prevent annoyances
1) Always, always exit the program, and start with a fresh client, before engaging in PvP
2) When walking through a gate, stand in front of it first, make sure you have a clear path all the way through, and execute one single click move order all the way through the gate. If you crash, you will not lose stuff, because on diconnecting, the character will still finish the command it was executing, in this case, walk to the point where you clicked (which is not in between the gate, but already through it)
3) before going on a canoe / boat trip, exit program and restart. On long trips, peridoically exit restart.
4) Don't carry a boat while in a canoe.
5) Exit restart before engaging argopelters.

[Procne]

Is this technical discussion, "for dummies" one or just a speculation thread?

Some observations:
- every single object has a memory leak. Some objects leak more than others (cotton fields, windmill animation).
- shadows count as object for this purpose too.
- loading a new map (by entering /exiting a building or teleport) does not clear the memory leak, it keeps accumulating. Since a new busy map will give it rather large shot of new objects to leak from, a lot of crashes seem to appear after a reload.
- Those spots on the map that will cause your minimap to update when crossing them are also notorious for pushing you over the OOM edge.

That doesn't make much sense. What do you mean by that?

- turn off shadows. Reduce crashes to half.

"citation needed"

- don't build (many) windmills
- minimize cotton planting, or make a separate base just for planting cotton, so it doesn't lag your main base.

[/quote]We were talking about OOM crashes, not lags

[martinuzz]

Is this technical discussion, "for dummies" one or just a speculation thread?

It's based on observations of me, village mates and friends over about 8 months of experiencing ender crashes.
You don't have to believe me, but I posted this thread to be helpful. If it was a technical discussion, I'd have either posted it in bugs & technical, or maybe in the ender client thread.
Since this is a problem I keep hearing about from many people, I thought it would be nice to post this here.

Some observations:
- every single object has a memory leak. Some objects leak more than others (cotton fields, windmill animation).
Based on abservations of crash frequency, while wandering wildlands, while in a small base with few objects, while in large bases, while in bases with / without windmill, with or without cotton fields, over 8 months of playing.

- shadows count as object for this purpose too.
Based on experimenting with shadows on and off, and it's effect on crashing frequency.

- loading a new map (by entering /exiting a building or teleport) does not clear the memory leak, it keeps accumulating. Since a new busy map will give it rather large shot of new objects to leak from, a lot of crashes seem to appear after a reload.
Well, they do, don't they?

- Those spots on the map that will cause your minimap to update when crossing them are also notorious for pushing you over the OOM edge.
Haven't you noticed that when crashing in your base, it tends to happen on specific areas?

That doesn't make much sense. What do you mean by that?

Edited in some clarification.

- turn off shadows. Reduce crashes to half.

"citation needed"

"I guess you didn't do any testing on this at all."

- don't build (many) windmills
- minimize cotton planting, or make a separate base just for planting cotton, so it doesn't lag your main base.

We were talking about OOM crashes, not lags

Oh, I'm sorry for mistakenly using the word lag. I meant crash. It DOES cause lag for people as well

Now was this bashing of a helpful thread really nescessary?

[Greb]

Helpful thread, thanks

[Procne]

Edited in some clarification.

No, really. What do you mean by "object has a memory leak". You start using technical term, but what you are saying does not make techical sense. So I'm asking where do you get those conclusions from?

"I guess you didn't do any testing on this at all."

Indeed, that's why I asked for more info. You are not giving observations, but your conclusions from said observations without giving your reasoning. With shadows being handled by OpenGL / GPU with almost no impact from code there really isn't any way for shadows to cause memory leaks. It might be possible that using shadows increases memory usage, which in turn leads to OOM crash faster. But it sure does not cause memory leak.
So my guess is, you had a few people testing on different machines with different client configurations, which you did not take into account, and then you all kept guessing.

Same for increased amount of objects and geometry. Geometry itself shouldn't be causing memory leaks. If it would then client would crash much sooner.

Some of my observations - crashes tend to occur faster if I travel a lot. If I stay in the same place they are rare.
If I combine it with the well-known bug of corrupted map when, after teleporting, you see terrain from some other place (often the one from which you just teleported) then I come up with the following conclusion:
When you travel your client keeps minimaps in the memory. When you teleport those minimaps are not flushed. Your client simply is given new, randomized coordinates. That's why after teleporting you no longer have the minimap of the old area - the client still has the minimaps, but they are for different coords. So as you travel those minimaps keep stacking until you crash. And that's the leak - client keeps loading minimaps but never unloads them.

More objects, which mean more geometry simply increase memory usage of the game, but they are not "leaking". Increased memory usage simply means that less memory can be lost due to leak until game crashes.

[martinuzz]

Okay, I do not use the term 'memory leak' as an expert here. I'm just putting one and one together.

Some of my observations - crashes tend to occur faster if I travel a lot. If I stay in the same place they are rare.

Travelling a lot will eventually add up to a crash, as far as I can conclude, because you do encounter many objects on your travel.

However.
If I go wandering about, through mostly uncivilized lands, I crash about once every 1.5-2 hours.
If I am tending my base, farming, building coalclamps, all within a very small area, without travelling much except inside my base, I crash about twice an hour. My base has tons of objects.

Back when I was a noob hermit, with a little camp consisting of 2 or 3 boxes, hideracks, a leanto and a claim, I would indeed crash more often when wandering longer distances, than I would when I stayed near my camp and did some fishing and cooking.

This makes it very likely, that it's the number of objects that eventually cause the OOM crash.

If I combine it with the well-known bug of corrupted map when, after teleporting, you see terrain from some other place (often the one from which you just teleported) then I come up with the following conclusion:
When you travel your client keeps minimaps in the memory. When you teleport those minimaps are not flushed. Your client simply is given new, randomized coordinates. That's why after teleporting you no longer have the minimap of the old area - the client still has the minimaps, but they are for different coords. So as you travel those minimaps keep stacking until you crash. And that's the leak - client keeps loading minimaps but never unloads them.

More objects, which mean more geometry simply increase memory usage of the game, but they are not "leaking". Increased memory usage simply means that less memory can be lost due to leak until game crashes.

I've only had said 'well known bug' 3 times in all my 8 months of playing. I think the OOM error is not related to that at all.

[MagicManICT]

One has to understand a few things about both OpenGL 1.x and Java to really diagnose these things.

I'm not experienced enough in OpenGL to give too much of a technical dissertation on it, but it has some serious shortcomings, one of which is that it is horrible about utilizing the 3D hardware on a machine. More recent versions have resolved this. Depending on the shadow type, they can use almost no memory or a good bit, but since this is the old school OpenGL, they use almost no memory but do take up processing time to render. This is processor time that can bottleneck and cause crashes, so turning them off MAY help on some systems.

Same thing goes for the windmills and cotton fields. Someone has a 1x1 field tile in Artifice & Arcana. This should help with the cotton fields causing issues. Large numbers of fields in their final stage of growth do crash a lot of players for some reason. Others don't crash, but lag up severely while loading. (Note: I don't recall windmills causing issues for anyone, but I could be wrong on this, and it's one less thing to be processed.... your mileage may vary.)

Java doesn't have memory leaks. Period. The problem is when the garbage collector can't run. When a program hogs the processor and the low priority garbage collector gets put to the back of the processing queue, a similar phenomenon happens, though. This can be worked around by using Task Manager (or a similar program) to monitor memory use. If it starts inching up too far, minimize your window or log out. Wait a minute or so, and then go back to what you were doing. Either of these should give the collector time to finish its process and clean up the unused memory. (FYI, objects don't have memory leaks, the executable has a memory leak. This is caused by failing to clean up memory it allocated to store an object and then never released the memory back to the system/heap after the object was unloaded/released.)

[Procne]

Java doesn't have memory leaks. Period. The problem is when the garbage collector can't run. When a program hogs the processor and the low priority garbage collector gets put to the back of the processing queue, a similar phenomenon happens, though. This can be worked around by using Task Manager (or a similar program) to monitor memory use. If it starts inching up too far, minimize your window or log out. Wait a minute or so, and then go back to what you were doing. Either of these should give the collector time to finish its process and clean up the unused memory. (FYI, objects don't have memory leaks, the executable has a memory leak. This is caused by failing to clean up memory it allocated to store an object and then never released the memory back to the system/heap after the object was unloaded/released.)

Just because Java has garbage collector and handles memory allocation automatically doesn't mean there can't be memory leaks. If you keep creating objects and keep them in a collection, even when those objects are no longer used, but collection is, then garbage collector won't touch them. In this case cached minimaps and terrain info is not flushed and keeps stacking. Whether it's the only cause of memory leak in Ender's client - I don't know. But I think you could "clean" it in Ender's client by enabling and then disabling minimap saving. I noticed then when you do so minimap is flushed, at least in GUI. I'll try to check if it frees up some memory.

[MagicManICT]

Good point, but enough RAM would, in theory, prevent this. I don't have a machine with more than 2GB, so can't really test it, but I don't seem to have these problems myself when I do play. (Overusing a collection and filling the memory up isn't quite the same as a leak, though, but still produces OOM errors.)

[Procne]

Maybe this extra RAM would help, but I'm not sure. I don't know what impact do those 2 lines from .jnlp file have:
<java version="1.6+" max-heap-size="512M" />
<j2se version="1.6+" max-heap-size="512M" />