Xenia: Invalid Threads

[ReservedRegister]

Xenia Memory Leak

As I loaded a game that lets me play campaign I noticed that memory usage increases and keeps increasing until it gets to a point where Xenia crashes. Discarded memory does not release, how I found out it does not is by playing the campaign for some time, then I quit to main menu I saw that memory usage did not decrease and that's how you would know it is a memory leak. Just to be sure then I attempted to prepare a custom game, but as it was loading the map it crashed.
I have recorded this happening - notice the memory usage (private bytes bar)
To see when I quit the game skip to 6:01
https://www.youtube.com/watch?v=08du4ojiAcQ&t=23s

What should have happened is when I quit the game memory usage should have decreased, but instead it was still increasing.

xenia.log

[ReservedRegister]

Any ideas on how to look into to solve it? :)

[ReservedRegister]

I am clueless of where to start from. I don't understand why it is not releasing the memory, if it does not game crashes. Maybe there is a reason to why memory does not release caused by a bug or not. But if memory does not release at some point it is going to use up all available memory allocated and its going to crash like it has.

[Triang3l]

I don't know if this involves textures, but they are never destroyed yet because of my laziness. About other things — I have no idea. But things like graphics pipeline states are never destroyed because their size is negligible, while the costs of recreating them are noticeable. Though it's possible that it's not something in the GPU code.

[Triang3l]

Texture memory leak fixed in d0c872527015ef90b4efd6e7d7996479de590a47, framebuffer memory usage still unbounded (but it's not that important).

[ReservedRegister]

In the April 5 Build I noticed that memory was controlled around 2.0-2.2GB and running out of memory would no longer be a problem.

BUT.

It still crashes at the same point, just like before. (from YouTube video)

Here is a video without stats - same mission:
https://youtu.be/vVNYtMdbhHw

Here is a video with stats - same mission:
https://youtu.be/YrNXPzIAahQ

I don't think the cause is Xenia's ability to emulate the game, because I have seen others get further than me in the game compatibility page. (also don't think its my hardware)

I think the cause is incomplete implementation of the new code added to support memory management. I don't understand the code so I would not be able to help you. You might have missed something, there was no reason for Xenia to crash as far as I saw, so there might be some old code interfering or something else such as erroneous code.

Intel Core i7 4790k
NVIDIA GeForce GTX 6GB
DDR3 8GB 1333MHz

[log file was 625MB so no log file]

[ReservedRegister]

Just confirmed that the cause is NOT Xenia's ability to emulate the game because just like in the video in my first post I quit the game to check if it will still crash and it did, showing that the problem must be something to do with incomplete implementation or something like that.

[ReservedRegister]

I also noticed that when I press on clear caches or F5 game crashes instantly.
Does this have anything to do with the game crashing just later?

[Triang3l]

Now or in some older version? Because previously I forgot to remove memory write callbacks for texture ranges when deleting, that's fixed now.

[ReservedRegister]

On the latest build.
Shows a white screen sound plays for a bit and crashes.

[ReservedRegister]

wait wait wait

[ReservedRegister]

apparently there is a April 10 build, it works now.

[chris-hawley]

i'm putting this here so we can persist the information outside of discord.

What's happening: Halo 3 crashes. (occurs in other games as well)

Where: On Sierra 117, if you start at the beginning and run to the end, it'll crash at rally point bravo.
On Crow's nest, if you start at mission start, it'll crash back in the hallway after clearing the hanger.

Each time I run it through the debugger, the crash happens at different points so i'm thinking that it's as a result of undefined behavior and/or memory corruption somewhere. I compiled Xenia with Spectre mitigations and that causes the crash to happen sooner so maybe that means it picks up on the problem earlier. I don't know how to proceed on debugging this since it's not always in the same spot.

So far, the debugger as shown the crash in the logging system, switching contexts (in window kernel) and callimpl. Since all of those happen numerous time a second, i'm not sure what kind of corner case wouldn't be found fairly quickly and only occur at certain points.