Client crashes upon clicking "Save and Quit" in game

[Lorelando]

Upon clicking "Save and Quit" in game, the client crashes. It happens often, but not reliably. It appears to be caused by an interaction with some other mod I have installed, I have however not been able to find out which one it is. The crash only occurs upon quitting the game and also only when Dynamic surroundings is installed.

crash-2021-10-30_15.38.24-client.txt

I'll try to test specifically which interaction is causing the crash. If you have an idea, what might be causing it, I'm quite willing to test it.

[JustCat80]

Can reproduce, but not sure of the exact cause as it seems slightly random, i was attempting to narrow it down to a specific mod but when i added them all back it works fine. Then after reopening, moving a bit, and attempting to save again, it crashes

[JustCat80]

It seems to be whenever the music kicks in but i am not 100% sure

[JustCat80]

Yep it is, was able to reproduce with only Mod menu, fabric api, and Dynamic surroundings I was underground and waited for the music to start playing, once it starts playing and you attempt to save and quit, the game crashes. crash-2021-12-13_13.32.03-client.txt So, its not a mod, its just the music

[ThexXTURBOXx]

I was able to reproduce this with Not Enough Crashes installed, which gives a better stack trace: https://pastebin.com/xLJA62ci

Also, I have music disabled. Thus, it can't be the music in my case here and it needs to be something else

[HarvelsX]

Here's an "understandable" log for you. I hope it helps, but it didn't help me much. It happens because the Source being closed in SourceManager from Channel does not exist in SoundEngine, which can only be created through Channel, which exactly registers it in SoundEngine, which causes the crash. Hmmm, I'm looking here and it seems it can only be when Source in SourceManager is null, needs research on this problem!

Also try testing this with the standard Client.Config.soundSystem.streamingChannels parameter (streamingChannels) in 8.

I'm sure you will solve this problem quickly!

debug-1.log

[HarvelsX]

It can't be null either, maybe we should consider org/orecruncher/dsurround/mixins/audio/MixinSource.java?

[ThexXTURBOXx]

It can't be null either, maybe we should consider org/orecruncher/dsurround/mixins/audio/MixinSource.java?

I already looked at that one. I am pretty sure there is a unregistered channel (or one that is not correctly registered)

[HarvelsX]

I can not figure out what is causing this, I hope you can solve this problem. I will be very grateful to you for an explanation of the solution to this problem!

[HarvelsX]

I already looked at that one. I am pretty sure there is a unregistered channel (or one that is not correctly registered) Why do you think so?

It's just that Minecraft itself creates one Channel instance, and the error says that Channel.sources has elements that aren't in SoundEngine.(streaming/static)Source, which shouldn't be and can't seem to be.

The Source itself can be null, by the @Nullable annotation inside SourceManager. I can assume that the Source at the moment of SoundEngine.release is null.

Maybe I don't understand something?

[ThexXTURBOXx]

I can assume that the Source at the moment of SoundEngine.release is null.

Nope, I already looked at that. Using a Mixing at HEAD of release(), which prints out the source to release, there is no null source

[HarvelsX]

Oh, okay

[ThexXTURBOXx]

I think, I am now pretty sure I know what is going on: The release function is called somewhere on the render thread, which should not be done. That leads to the channels being released two times since the threads are not synchronized (they don't need to as this shouldn't be done on the render thread anyways). So, sometimes the instances are being released twice because they still remain in the SourceSet despite being already released due to the bad synchronization. I am now trying to track down the faulty call to release.

Here you can see what I mean (RH is at the HEAD of the release function, RT at the TAIL):

[HarvelsX]

Heh, I see, thank you very much for the explanation!

[ThexXTURBOXx]

Opened #17 with a workaround (not a fix!)

[HarvelsX]

Is it possible that after this.taskQueueue.restart(); the modification tries to play the audio while ignoring the playback stop? It looks like the audio processing in this.taskQueue is happening while this.channel.close();, and at that time the processing in this.taskQueue in the Local Client thread is simultaneously with this.channel.close(); in the Render thread trying release.

this.channel.close(); in a Render thread for the Minecraft is more than normal practice