[Neuro Toxin]

Im sure you know whats going on.

[Chief149]

There appears to be a very rare memory leak going on where SourceMod closes your plugin. This might just be Sourcemod being dumb, but I wanted to mention this.

Why no copy/paste of the error, you say?
This happened once, and I saw the error. I thought it was just a rare fluke, so I disregarded it. Plus I thought it would be in the logs anyways. Ever since then, this has only occurred when I am not watching the console. The normal logs, command logs, error logs, etc all do not include the memory leak error.

There probably isn't much you can do from this without a paste of the error in console, and I will include it, but I have to spot the error actually display on the console before I can do that since it isn't logging at all lol, but I wanted to make you aware of it.

[Neuro Toxin]

Is it this?

[Chief149]

YES!

I have personally been trying to figure out a solution myself after finding out it was happening, but because I could never see the actual error message, I couldn't think of anything to do about it.

But now that I see that (which I never would have expected to find if I did a search tbh, but now I see I should have done a search), I can figure out a fix.

However, there really needs to be a way around that issue. I personally have been good at cleaning up my dynamics, so idk why this happens. I did modify your plugin to not destroy handles and other dynamics stored by a dynamic that is being disposed. I wanted fine control of that within my plugin. I will verify that I didn't introduce a glitch to cause the issue myself.

[Chief149]

Ok so I can confirm that I did not break the version of your plugin that I am using. All I did was comment out the if statement that contains the code for disposing a dynamic object's members (if they are handles or other dynamics). I have dynamics representing clients which store other dynamics that then reference the client object (cross reference). So for safety reasons I just made sure that disposemembers could never happen when a dynamic is disposed.

[Neuro Toxin]

.Dispose has a disposemembers param. It's default value is true. If you .Dispose (false) Dynamic wont dispose it's members.

With not disposing members you need to be careful that you dont loose references to Dynamic/Handle type members. Doing so will cause Dynamic leaks that will ultimately cause SM to kill Dynamic for being a Handle hog.

Edit: As more and more plugins use Dynamic i think its unsafe to modify the default behaviour. Other plugins could cause leaks as they expect Dispose(true) to clean up their trash.

Not exactly sure what you're upto, I would be willing to see what solutions can be reached to solve your problem that dont impact other plugins using Dynamic.

[Chief149]

Well I currently do not use any other plugins that use dynamic, and I do actually keep up with all of the dynamics.

I am not denying that I failed somewhere to clean up after myself as far as me being the one leaving a leak. I made a command that I will test later that will tell me if the number of entities my own plugin is tracking differs from the number of entities dynamic claims to have (dynamic should have one object more than my plugin due to dynamic using one object for the global config).

If my plugin is tracking X dynamics, and s_CollectionSize isn't that different from X, then that means there is a glitch. Otherwise it is likely a memory leak within my own plugin.

My plugin is an rp plugin so there are many cases where dynamics are being created and destroyed when it comes to items and money being dropped and picked back up. So far I have checked as many usage scenarios and other scenarios where a dynamic is considered finished by my own plugin, and each of those codepaths result in the dispose method being called. But later tests will decide what is going on.

[Neuro Toxin]

To clarify.

settings = view_as<Dynamic>(0);
clientsettings = view_as<Dynamic>(client);

So the default dynamic count is MAXPLAYERS-1

Edit: I've also been thinking of adding a dynamic usage command which prints the count of objects each plugin owns.

[Chief149]

That would be nice.

I have found that somewhere in my plugin is a memory leak, so I just added an object registration system. Every object my plugin makes goes to two lists. One list is used by my plugin and the other is used by the garbage collector. If the object isn't in list 1 but it's in list 2 then it's been orphaned and needs to be terminated.

[headline]

Haha, I've come pretty far since my first question a little less than a year ago. It's funny I had no idea what a method, class, or object was. Oh well!

Anyway

Originally Posted by Neuro Toxin I have some planned changes where <dynamic>(1-maxplayers) will always relate to data for the corresponding client index that auto initialises and disposes with client connect and disconnect events.

I know this was long ago, but is this going to happen? It'd be very useful information to be able to access automatically without having to implement into every plugin. Perhaps I could do it myself in the form of a plugin, but I'd like to see it incorporated regardless