good day!
so, context: rain world is a game that due to not having been made in unity natively runs as a widget running a ton of C# code under the hood. and also as far as i remember the following situation happens: something throws exception, it gets catched and logged into exception log, but in the stacktrace it looks as follows:
MainLoopProcess.RawUpdate (System.Single dt) (at <f4695e3431e24c62b24e6b9c3fcc19b0>:0)
RainWorldGame.RawUpdate (System.Single dt) (at <f4695e3431e24c62b24e6b9c3fcc19b0>:0)
ProcessManager.Update (System.Single deltaTime) (at <f4695e3431e24c62b24e6b9c3fcc19b0>:0)
RainWorld.Update () (at <f4695e3431e24c62b24e6b9c3fcc19b0>:0)
at the end of each line there is a bunch of numbers instead of a path that says where exactly the throw happened. this usually happens when there are no valid debug symbols to load
so, i tried to move debug symbols shipped with game in another folder to the folder assembly-csharp is in, to no success. i assumed it may be due to mismatch between dll and pdb and with dev permission recompiled game code to generate a truly valid pdb, but i had no success either
to wrap this in some context: i mod said game, and if pdb is included correctly with the mod, the lines associated with mod are shown as paths in stack trace
all of this is being done in attempt to profile memory to figure out why some of most major blocks never get freed, or more precisely what exactly keeps reference to them. as of currently using visual studio built in profiler shows that all code that is being executed is private memory, with zero data on what’s happening in project’s binary, and i assume that’s due to code’s inability to map binaries to actual code, which is the functionality pdb provides
the line of questions is:
is my assumption that to profile the game via mvs i need pdb correct?
what do i need to do for game to load pdb?
if i am doing profiling in the wrong way, how do i find out what keeps reference to an object, withholding it from freeing the memory? simply finding it in code is a barely accessible option, because within mainloopprocess there are references from parent object to child object and vice versa, so leak of anything inside mainloopprocess is enough to leak the entirety of it