Not exactly, terminating the process will unmap it all. If a /reload works, it means it’s still within their LUA sandbox, which is within the wow.exe process. The default UI is within that LUA sandbox. A /reload likely triggers that sandbox to clear itself out.
Lol, no. If the RAM was garbage collected when the program quits, it’s not leaked RAM. Leaked RAM is still possible when coding in C++. All you have to do is allocate memory and then forget about it.
No, it’s really not… Windows virtualizes all memory addresses for programs. It always knows what addresses a program is mapped to. It’s to prevent things like memory leaks permanently taking up ram until a reboot. Been like that for many years now.
If you have an app that has a pointer to some exact physical address, it doesn’t actually map to that real address in the real ram. It’s a virtual mapping and when you kill a process, it kills that virtual mapping. Sandboxing in a nutshell. You’d need injectors/viruses to get around protections.
It’s been debugged to be within their UI code. Specifically the LUA code responsible for the new crafting ui.
Specifically an array where an entry added to it after each craft, and gets retained until the sandbox the crafting ui resides in resets (reload or zone change).
Ignore the troll who is arguing semantics on memory leaks not being a thing in managed languages because you can close the app or the VM thread the memory leaking scripting resides in. They know exactly what we’re talking about and wanna argue like they don’t.
It’s not a one off and other people have noticed leaks as well. Snipping things I’ve said here as I’ve said them already earlier.
It’s the crafting history log iirc storing everything in full in plaintext. Closing it doesn’t reset nor pause the logging array. I believe the item icon is also copied for each entry, which probably accounts for most of the memory leaked.
Yep that would be it 100%. No way the plaintext could flood it that rapidly unless there were some broken loop shenanigans. Those icons are probably uncompressed as well since most UI elements don’t get compressed into formats like DXT1/5 and remain in R8G8B8, or at least that’s how we do it in UE4/5 based games that I’ve worked on.
But I definitely know and remember the transmog collections windows leak because it would flood your vram->ram in seconds if you wanted it to. With that one, I assumed it was from render targets not being garbage collected and those render targets are far larger in size than UI icons. Though the UI icons are surprisingly larger in size than you’d think. Want to say up to 256x256(192-256KB)? The UI leak right now though probably is using a lower mip of that I’d assume, like 64x64(12-16KB if they have alpha).
Still leaks in 10.2.
Still leaks in 10.2.5.
Not fixed one bit at all.
I think at this point someone is just spiting with not fixing it.
It’s the sort of thing you fix in alpha builds, not leave in production a year and a half later after golden master.
It’s certainly something I’d wish they’d get around to fixing – I want to work on my crafting, but the leak makes me wary of doing it for too long
Considering we’re stuck with the new crafting UI, and it would seem like a relatively easy fix, considering people outside of Blizz have tracked the problem down, it makes me wonder why they’re dragging their feet on this. Unless they’re being purposefully obtuse, or waiting for War Within to try and quickly tinker with it like they should’ve done over a year ago.
Counterpoint: RAM is a solid, not a liquid, so it cannot leak.
Checkmate, bug fixers.
Still leaks in 10.2.6
i have never had any issues with the crafting ui or my hardware
you should look into some pc hardware upgrades
Still fighting the good fight.
I pity anyone who does this.
Still Leaks.
Still leaks and it leaks in the TWW beta client.
It looks like it’s not gonna be fixed for an additional 2 years due to being present in 11 atm.
So two points.
- who the hell is spending hours on end doing non-stop crafting as opposed to just playing the game.
- The OP pointed out a solution to this problem 2 years ago: just type /reload which might cost you a minute or two if your on a laptop as old and jank as mine.
The only thing I’d add is that it is likely that Méòw is just the OP on another character. Look at which ones are the ones to necro this thread.
They are quite simply just a serial necro-threader.
It’s getting bumped every couple months by me because it seems it’s been forgotten about by the devs or they think it’s some other issue, as it would have been fixed by now otherwise.
Using /reload is not a fix, it’s a very terrible workaround whereas it still leaks you’re just literally reloading all the lua code to shotgun method it.
You’re literally the only person that seems to think this is a serious problem.
And reloading is a valid way of dealing with your game’s issues, particularly when you know that your pattern of behavior is causing it.