Describe the bug
I'm running into an issue of the game never completing a backup that starts either automatically or manually. After I updated the mod from 3.4 to 3.5, the game crashes entirely with every attempt to create a backup. The crashes appear to be unrelated to world size, but in 3.4 small worlds were taking correct backups, the large one never completed one even when I left the game overnight.
The world I am trying to backup is a former server world of ~10Gb in size that I pulled into my client originally to do a full journeymap scan. During which a backup tried to run and never finished, which is where I started diagnosing.

To Reproduce
Steps to reproduce the behavior:

1. Launch the game
2. Start backup in large world
3. Observe crash in mod version 3.5, or the backup never finishing in 3.4

Expected behavior
Well, no crash

Screenshots
If applicable, add screenshots to help explain your problem.

Versioning (please complete the following information):

• OS: Win10
• Minecraft Version(s): 1.20.1
• Modloader(s): Fabric
• Mod Version: 3.4 / 3.5

Additional context
Here are some logs:
https://mclo.gs/O1UupTK / O1UupTK.txt - backup never finishes
https://mclo.gs/tESF9RV / tESF9RV.txt - mod updated to 3.5, crash trying to create snapshot
https://mclo.gs/BGwCgdW / BGwCgdW.txt - tried to create backup after 3.5, crash on backup start

Thanks in advance for any help!

That's a crash in the jvm code itself? I'd hope that's a one off or yeah perhaps a memory issue, because nothing I'm doing should come close to having segfaults in the jvm code..

Oh boy, seems like the accesswidener isn't applying outside of dev.

I'll push a hotfix out in the coming days, along with some other tweaks - scheduled backups however should work.
The backup hanging you had should've been fixed with 3.5, but just to check - are you using differential or incremental backups with compression disabled?

I was initially using incremental, but for at least the last two logs I know for sure I have re-set it to be differential to exclude variables.

Differential and incremental backups are made in nearly identical ways, so that shouldn't affect much anyway.

With that being said, could you check the value of the config.advancedbackups.chains.compress option near the bottom of your config file?

Also, this jar should now fix your crash.

have one better, here's the entire config file:
AdvancedBackups.properties.txt

https://mclo.gs/igweCRr Well, so yeah that's a hard crash, it took my graphics driver with it. On the bright side the backup actually started this time and was making progress. I'm gonna guess this may be an out of RAM as I have a bunch of stuff open rn. My memory is overclocked too, but it survived an overnight memtest86 so I think I can trust it.

hs_err_pid1220.log
there's the rest of the error

Yeah, unfortunately not nearly my first full jvm hard crash. They tend to usually happen when a mod calls an external library for e.g. compression and something in that library goes horribly wrong possibly due to problematic input data. I've closed other programs and reduced the amount of maximum ram assigned to JVM and it took the large backup without problem now. There may be a crash here when the game is assigned more memory than windows can give it that something in the world compression handling goes wrong.

I'd expect an OutOfMemory error if it hit a limit, but with the huge amount you had allocated perhaps that's just not the case...?