krom_load_sound(): Invalid address specified to RtlValidateHeap

[MoritzBrueckner]

When loading a sound in Krom via kha.Assets.loadSound(), there is an error in main.cpp line 1369 (permalink):

HEAP[Krom.exe]: Invalid address specified to RtlValidateHeap( 000001F6EF450000, 00007FF6D986C9D0 )
Krom.exe has triggered a breakpoint.

The sound pointer is at address 0x00007ff6d986ca00, which is similar to the second address in RtlValidateHeap above.

Some answer on stackoverflow suggested that these errors happen if an address is freed that wasn't returned by any allocation call, so I watched the sound pointer inside of kinc_a1_sound_create() for value changes. Visual Studio then breaks in main.cpp line 1355, but the sound pointer still points to the same address, so I'm not sure why this happens. The pointer seems to be the same from it's creation until its memory is freed, so I'm not sure if this is the issue.

Then I tried to use kinc_a1_sound_destroy() like it is done in Armorcore, and even though this solves the error, the application will then run into an endless loop somewhere in Krom's kha.LoaderImpl.loadSoundFromDescription(), at least the done() callback is never called even though Krom.loadSound() finishes executing.

Using:

• Latest Krom from master (0f4120ca08fc5124eb8b26057ebc6da6f29d1c57), changed convert_vertex_data() to make things run (this needs an update to account for the new vertex formats!)
• Latest Kha from master (https://github.com/Kode/Kha/commit/3351b5a517f2e2995621de54ed0d145cbba2dd8e), no modified submodules, only some additional trace() calls to see what is executed when.
• VS 2022 (v143 platform toolset), Debug x64. The same happened before on VS2019
• Windows 10
• Running Krom with --sound parameter to enable sound

[RobDangerous]

The --sound option isn't really working yet, we already have issue #138 for that.

[MoritzBrueckner]

Just to make it clear, this issue also happens without the --sound param as it happens while loading a sound and not while playing it. I thought that the linked issue was only saying that the current way of doing audio is not great and temporary but that it would still work, but if that's not the case then yeah, I guess it doesn't make much sense to waste time on this issue right now.