Version

mc1.17-0.3.0+build.469

Reproduction Steps

1. Enter a world with this build of sodium
2. Game will crash after rendering some chunks

Crash Report File

hs_err_pid3292.log
hs_err_pid3755.log

Additional Information

The crash seems to be a direct java crash instead of a minecraft crash from the crash log that is provided. Also, it probably isnt the same as the other one i saw in the issue tracker as this is a SIGSEGV crash as opposed to an EXCEPTION_ACCESS_VIOLATION crash.

Also, system specs if needed, even tho they probably are in the crash log
CPU: Intel Celeron E 1500
GPU: (asus) radeon hd 6450
RAM: 3GB DDR2
OS: Pop!_OS 21.04

@HerbertBin If you're experiencing memory leaks with Iris, then it's a problem with Iris.

I believe that these issues should be solved in the latest release of Sodium, as we've made many improvements and fixes to this area. If users are still able to reproduce the problem originally described in this issue, please provide a new crash report with the latest version of Sodium and ask for the issue to be re-opened.

I believe that these issues should be solved in the latest release of Sodium, as we've made many improvements and fixes to this area. If users are still able to reproduce the problem originally described in this issue, please provide a new crash report with the latest version of Sodium and ask for the issue to be re-opened.

I can confirm that I am no longer having issues in the latest release of Sodium, 0.3.2. Not getting Linux malloc() process exceptions when rapidly changing view direction or using high render distances, and memory usage is never going above 1-2 GB, compared to consistently having 4+ GB before. I tried all of the same test worlds I did before, and tried on various servers where I was especially having issues.

Really glad this issue seems resolved so far as it made Sodium completely unusable for me otherwise, now I can use Sodium for more than 30 seconds haha

You might (probably, honestly) not have enough memory to load the chunks. What's your render distance set at?

Also SIGSEGV is basically the Linux equivalent of the Windows EXCEPTION_ACCESS_VIOLATION. It's just an out-of-bounds memory access that got caught.

My render distance is set at 8
The thing is that this error didnt happened with the previous build

I experienced similar issue with sodium-fabric-mc1.17.1-0.3.0+build.486. The game runs out of memory after playing for some time.
There is probably a memory leak in Sodium 1.17.

hs_err_pid4475.log
alright updated to the latest 1.17.1 build number 494 and it seems that this is probably still happening

The crash both has happened with 2 and with 8 chunks. I cant rrally allocate more than 1gb to the game or else my entire pc would just die (3 gb, go figure) but from my tests it never really went over 50-70% memory usage with only sodium/modded vanilla and 30-50% with hydrogen. Wonder what it could be

I am experiencing an issue that seems to be related, I'm not sure if it should go under a separate issue. I'm also on Linux. I did some investigation and it seems to be related to GPU uploading from within GLBufferArena.java but I don't have enough experience to really understand what's going on.

Most commonly I get a hard program crash, malloc(): unsorted double linked list corrupted. Looking on Google, this is an error specific to Linux and seems to generally be caused by buffer overflows. Sometimes I get other odd messages but very very rarely does that happen.

I tried switching all of the MemoryUtil functions in NativeBuffer.java and pretty much any other places I could find to use the "safe" versions of functions (e.g. memFree instead of nmemFree). This did not solve the issue but it did maybe give some insight into what's happening, as the malloc issue immediately turned into a Java error originating from GLBufferArena.java:
Buffer alloc length mismatch (expected ..., found 0) which is getting thrown from the tryUpload method.

I couldn't really dig into the issue too much and again, not having really any experience here I don't really understand the details, but, maybe the buffers are getting deallocated while in use? I'm definitely not running out of memory as this happens with over 13 GB free, with MC set to allocate up to 8 GB.

I am experiencing an issue that seems to be related, I'm not sure if it should go under a separate issue. I'm also on Linux. I did some investigation and it seems to be related to GPU uploading from within GLBufferArena.java but I don't have enough experience to really understand what's going on.

Most commonly I get a hard program crash, malloc(): unsorted double linked list corrupted. Looking on Google, this is an error specific to Linux and seems to generally be caused by buffer overflows. Sometimes I get other odd messages but very very rarely does that happen.

I tried switching all of the MemoryUtil functions in NativeBuffer.java and pretty much any other places I could find to use the "safe" versions of functions (e.g. memFree instead of nmemFree). This did not solve the issue but it did maybe give some insight into what's happening, as the malloc issue immediately turned into a Java error originating from GLBufferArena.java:
Buffer alloc length mismatch (expected ..., found 0) which is getting thrown from the tryUpload method.

I couldn't really dig into the issue too much and again, not having really any experience here I don't really understand the details, but, maybe the buffers are getting deallocated while in use? I'm definitely not running out of memory as this happens with over 13 GB free, with MC set to allocate up to 8 GB.

I tried modifying the minimum allocated memory and found something interesting.

These appeared to be somewhat stable minimum values for me (if I didn't turn my camera) but I couldn't figure out any magic amount for any of them, because sometimes when I launched the game 2 GB was sufficient but other times I needed to allocate more, likely because of memory spiking a lot differently when initially joining the game and loading chunks and such.

At 4 chunks: 2-4 GB
At 10 chunks: 4-6 GB
At 32 chunks: 10-12 GB

(Yikes)

I let the game sit for a while and didn't end up crashing as long as I stayed still.

However to make things worse, like I said, that's only if I stay still. The garbage collector seems to only collect within a certain percentage of the allocated memory. If I allocate 12 GB, it collects at about 8 GB usage, leaving only 4 GB available, and based on those above values, if we're assuming that turning the camera all the way around allocates 2x the memory until the GC period, in order to stably use 32 chunks of render distance I'd need to allocate about 30 GB of RAM in order to always consistently have that 10-12 GB available.

Seems like something around memory allocation is not playing nice at all, whether that be a memory leak or otherwise.

The malloc crash I'm experiencing is happening even all the way back in commit 55c1d4a, even before the new memory related commits.

I decided to check out a newer build of sodium (0.3.0+build+503) and it seems like the crash is no longer happening. No console errors, no unexpected chunk culling glitches, no no thing. Is this fixed? cause i think it may have been fixed. Not even the block face culling option affected any crash as of now.
I think this may have been fixed, but i gotta check this out a bit more before calling it done to see if anything happens

1.17 and 1.17.1 with #503 have some memory leak problem, slow but happening. Specially at 1.17.1 with Iris shaders.