Open KGoodale13 opened 7 years ago
They won't fix anything on MacOS, the same bugs have been here since gmod 13's release. They are doing it to spite mac users to follow in garry's footsteps, because garry said he would never fix any bugs on macos. Pretty sure they don't even know how which is weird because macos is the easiest platform to program on.
Sorry for bumping this issue, but the ToGL implementation for GMod should at least be updated to the new Source branch version.
Also, "macos is the easiest platform to program on." ???????????
The main reason that Mac issues aren't being fixed is because I'm pretty sure neither of the devs own a Mac. They could use Hackintosh but I'm sure that doesn't entirely accurately emulate a real OSX platform.
Details
For the past few days I've been trying to find the source of crashes on macs. What I've found is all the other issues opened for OSX crashes are symptoms of a larger problem. And that is the virtual memory of gmod getting filled when loading textures and materials and the majority of it never being released.
On both MacOS and windows I did the following:
On windows the virtual memory size went from 2.06GB to 2.13GB On Mac the virtual memory size went from 3GB to 3.6GB, each new car spawned added anywhere from 10Mb->80Mb of memory.
If I continued spawning new cars on mac the memory will continue to grow until hitting 4GB. All the other crashes are a result of this bug consuming almost all the virtual memory and leaving everything else like 0.1GB to work with, eventually some process attempts to malloc some space and since there is none this will be thrown
What's eating all that memory?
Not entirely sure, I'll attach the memory profiles so you can look. There are some memory leaks but they don't account for much. The togl library seems like a likely candidate. I also noticed that there are thousands of vertex buffers chilling in virtual memory that never get removed not sure if they are meant to be there or if its a leak.
Memory leaks:
libtogl.dylib IDirect3DTexture9::GetSurfaceLevel(unsigned int, IDirect3DSurface9**) It's only 80 bytes but for every car I spawned there were up to 7000 of them created and left to live a lonely life (Actually they probably aren't very lonely because there's hundreds of thousands of them). I'm not sure if it gets called anywhere else but all the calls to this function that leak come from shaderapidx9.dylib functions BlitTextureBits, LockTexture and SetRenderTargetEX.
libvstdlib.dylib CKeyValuesSystem::AllocKeyValuesMemory(int) I'm not sure if this is actually a leak but its 32 bytes and there are thousands of them chilling in memory.
Side Note: TF2 seems to have updated togl 3 years ago and in their commit it had a lot of conditions added for OSX. https://github.com/ValveSoftware/ToGL/commit/f977441c2ac4e2727beda419633a7279737a3541
Steps to reproduce
Launch gmod on mac subscribe to some car packs on the workshop launch single player (or join a server if you can spawn stuff) spawn a bunch of different cars watch your virtual memory climb and wish your bank account would climb that fast
Data
Instrument memory profiles (Need a mac to view) instrument-profiles.zip
Persistent Virtual Memory after spawning about 18 cars PersistentVirtMemWhenSpawningCars.txt
Really deep stack trace when loading a shader largestacktrace.txt
Example Crash (Although I can reproduce all the other mac crashes by having less cars so it doesn't fully fill memory and instead something else will be the staw that broke the camels back)
crash.txt
Other crash issues I've been able to replicate by filling memory to almost max but not quite so something else causes the crash.
2962
2937
2206
888
607
2268