Bobby

Bobby

4M Downloads

Memory Leak in Mangrove Swamp

PeculiarPineTreePlays opened this issue ยท 4 comments

commented

Hi!
Thanks for making the Bobby mod. I'm using it to make cinematic-style intros & timelapses combined with Replay Mod, and it worked really well in episode 1! However, for episode 2 I moved to a mangrove swamp, and my client keeps crashing.
Client I'm using is here: https://www.curseforge.com/minecraft/modpacks/recording-client-for-locals-mc-server

It's a memory leak, but the logs won't tell me which mod is causing it. It only happens with higher render distances of "fake chunks" though.

I disabled every mod except for:

  • Fabric 0.14.9
  • Fabric API 0.62.0 (tried the newer version too, same thing. )
  • Bobby 4.0.0
  • Freecam (fabric) 1.1.6
  • Mod Menu 4.0.6
  • Sodium 0.4.4+build.18 (tried disabling it, but FPS was so bad I couldn't run the test properly)
  • ReplayMod 2.6.8
    and it still persists.

Steps to reproduce:

  1. Set render distance to 24 or 32 (I tried both, more chunks = faster leak)
  2. World seed = 3324100555488929243
  3. TP to coordinates: -4814, -2962
  4. I dug a little hole just under the surface, and flew Freecam straight up to below cloud layer (my friend tried without freecam though (in creative mode), and same thing).
  5. Wait for most chunks to load in, then turn 90 degrees
  6. Repeat step 5 (turning the same way every time)
  7. Keep turning periodically every so often.
  8. Every time you turn, MC RAM usage (in Task Manager) increases by 100-200MB, till it reaches max MC RAM (8GB allowed in my case). Interestingly MC F3 screen & task manager wildly disagree, with MC saying only 1.5-3GB-ish used.
  9. Crash says "EXCEPTION_ACCESS_VIOLATION"

Other notes:

  • I've tried with/without MemoryLeakFix mod. No difference.
  • Server render limit is 10 chunks
  • Happens in Survival & Creative, but I couldn't get my camera account to crash in Spectator mode.
  • Using MC 1.19.2
  • "Taint Fake Chunks" is disabled

Let me know if you need any more information,
Thank you,
Robert

commented

Hi, thanks for the extensive report and reproduction steps. Unfortunately I'm unable to reproduce the issue (creative; also flew around a bit to get about 32 chunks range cached first). Once all chunks have loaded in, memory usage stays pretty much constant for me regardless of how I turn.
Do note though that the memory thing might be a red herring: Java has a bunch of internal memory pools that it manages, and for most of these once it has allocated memory from the Operating System, it usually doesn't give it back, even if it doesn't currently need it (because there's a chance it'll need it in the future, and asking the Operating System again is much slower than just keeping it around just in case). That's why the F3 screen disagrees, the first number it shows is actually-in-use memory, which the OS cannot see. So MC's memory usage as seen by the Task Manager increasing up to the configured limit isn't necessarily an indication of a memory leak (and it did increase to the configured limit of 4GB in my case as well; just much quicker cause it's a lower limit).
EXCEPTION_ACCESS_VIOLATION is also not typical of a memory leak. Usually that's a programming error in one of the drivers (or any other native/non-Java code). With these types of crashes, the game (technically Java) should have generated a file starting with hs_err_pid in the .minecraft folder, that should have more information on where/when exactly the error occurred.

Would also be helpful if you could narrow down the mods further, i.e. check if you can still get it to crash without freecam, bobby, mod menu, fabric api and/or replaymod. If that's the case (or if it's a graphics driver bug), it might also be worth a shot to ask in the Sodium Discord, I'm sure they must have seen a whole bunch of those by now and might recognize yours.

commented

Thanks for the detailed response. It's helped clarify a lot of things.

What's been happening, is it's been increasing to the 8GB limit.... then increasing beyond the limit (to 8.5-8.8GB or higher), then crashes.
For my friend, it increased to 24GB RAM, then crashed (guessing it went beyond the limit in his case too?).

I've attached the latest crash log, in case it has anything helpful in it?
I've tried reading through it, but I can't make sense of it with my basic programming knowledge.
hs_err_pid4992.log

In the mean time, I've continued using the modpack (release version, with all the mods). The memory thing only happens in that one swamp. Everywhere else it stays around 4-5GB in Task Manager (despite being capped at 8GB) & doesn't seem to climb higher. But as soon as I enter the swamp it slowly increases.
(Staying at 10 chunks render is fine, keeps it at 3.5-4.5GB or so).

Could it have anything to do with the fact that I've loaded far more than 32 chunks there? For my dramatic intro to look right, I had loaded about 50-60 chunks (surrounding that lonely mountain peak), then afterwards set render distance back down to 24.
I had suspected it was loading "fake chunks" beyond the 24 render distance, then realizing it couldn't display them, then not discarding them properly, so that when I rotate back that direction it wouldn't realize it already has that in the RAM, and loads it again essentially duplicating that portion of the RAM. That would seem to explain the behavior of the crash, but it's only an idea.

As you said, the whole RAM thing may be a red herring.
When you said "programming error in one of the drivers", are you referring to my Java installation version, or GPU drivers?

I'll try sending a report to Sodium too.

commented

Hi again,
Looks like this issue is solved for 1.19.3! Looks like it was a Sodium bug. Sodium released an update recently that mentioned fixing a "memory leak" issue. I've recently updated all the mods to 1.19.3 and have had no issues so far, so that's probably what it was. Guessing Bobby just amplified the leak due to having so many chunks loaded (i.e. not Bobby's fault).
Too bad Sodium didn't release that fix for 1.19.2, but that doesn't really matter much.

One question though:
The "bobby-fallback" world... wondering if I had set it up wrong, or am misunderstanding what it does?
I understood that if you're on a server with a limit of 10 chunks, but you set your game to 64 chunks, that your first time logging on it'll load all 64 chunks from "bobby-fallback". Instead what seems to be happening is it'll load ~12 chunks & stop (i.e. there's a small ring of "fake chunks", and that's it. Couldn't tell if that's from "bobby-fallback" or just from wandering around slightly). Anything else had to be explored manually to "cache".
(This is referring to the 1.19.2 version of Bobby if that's relevant).
Planning to add fallback back into the modpack for 1.19.3, but not sure if I was doing it right.
(Sorry if I'm missing something obvious.)

Thanks for your help earlier! :D

commented

Your understanding of the fallback world sounds correct. Though only if the 64 chunks are already present in the fallback world, they will not be generated, only loaded. Also note that the dimensions must match. If the server is for some reason using a custom dimension id instead of the vanilla overworld, then the fallback world must use that as well.
If you need further help with this, please open a new issue for it, so that people potentially subscribed to this one don't get spammed with notifications.