Module Unload Helpers?

Is there any kind of helper/sanity check you guys have to assist module authors to remove all references to UI / memory your module has created and manages before it’s unloaded? That way modules doesn’t create duplicate windows, or menu items or leave stale event handlers…etc.

Currently, we don’t have any sort of sanity check of that sort. If you use only weak pointers across modules and no shared pointers, there should be no memory leaks when a module gets unloaded, as all the weak pointers will invalidate themselves at the correct times, and you simply need to query if the weak pointers are valid to see.

What is exactly the issue that you are running into?

Hi Zane, I was more concerned about module reloads without restarts when I ran into this. Extension points holding onto smart pointers and difficult to diagnose crashes with no engine stack trace.

Figured it would be worth asking if there was a way to add metadata to allocations to track the module that allocated the dead pointer.

Well, the idea behind extension points would be that in a new module, you would AddExtender’s on module startup, and then RemoveExtender on module shutdown.

Having metadata which ties your smart pointer allocations to specific modules is an interesting idea. We don’t have anything like that, but it might be interesting to consider for future releases.

Generally, the workflow for smart pointers is one of two things: If you just need one off data, pass weak pointers to other modules, and the other modules should simply be vigilant for the weak pointer invalidated OR (as the extensions manager currently works), have an Add and Remove pair of functions which are meant to be called at module startup and module shutdown, respectively.

This got me thinking, the UI calls GetAllExtenders(), that clones and flattens the array of extenders with combine right? Doesn’t seem like RemoveExtender would have any effect on the cloned list of extenders on shutdown and we’d continue to persist a copy of any smart pointer delegates in an extender.

Maybe the policy should be to only use weak pointer delegates in extenders?

As mentioned before, UIs are not automatically regenerated until you reload or recompile the module which houses that UI. As such, removing an extender will not take effect until the reload (and using a weak pointer will not make a difference here either), since extenders are only used at UI creation time.