Your comments

Hi Lazlo,

Seems promising! It's definitely fixed all of the known Bolt leaks. There's still a bit of confusion on our end as we're still leaking memory in general and Bolt is still showing up in some of the root paths, but I *think* that's down to problems in our code rather than yours!

We're investigating now. I'll let you know what we find.
Thanks!

Rob.

Cool :-) 

I'm off now, but if there's anything new on Monday morning I'll give it a go then and let you know.

My other backup plan is to just replace all of our macros with code. I think it'd be pretty easy to write a node equivalent to our PlayTimelineAndWait (and a couple of other similar ones), based on the WaitUnit code. 

(Obviously that doesn't solve your problem in general, but it might take the pressure off a bit!)

Yeah, that does completely break the game. Loading the same level again after clearing the dependencies causes Bolt silently fail (presumably waiting for its dependencies to be available)

Worryingly, it also doesn't cure the leak. It reduces the paths to root from 4 to 3:

Incidentally, as a short-term measure, would loading an empty scene then forcibly clearing the dependency cache cause any problems? At this point I'd settle for a safe-but-hacky solution!

OK, that's interesting. The example is pretty contrived, so I'm not 100% sure that it's the same cause as the examples in our game. It's obviously still a problem in general, but I might do some more tests and try to find a reproduction that more closely matches our in-game usage.

Thanks! Looks good in the test project. I'm trying it in our main project now.

One immediate problem is that AOT pre-builds now fail:

(The top line of that got cut off - it's a null reference.)

Update: Looks like it's still leaking:

I'll try to update the test project to reproduce this.

Update 2: I've reproduced it, albeit with significantly less paths to root than in our game (it's only one in the test). Here's an updated test project:BoltMemoryLeak3.zip

To see the leak, in Heap Explorer open the "Investigate" section of the top 20 native memory usage, and search for Cat. It seems to be caused by the direct reference to the texture inside the bolt script, where it uses it to set a material's texture. Just having it indirectly referenced by the Playable Director no longer causes a leak. Here's the path to root that I get from the test project:

Awesome. Good luck!

Hi Lazlo,

Thanks for the clarification. Is there an ETA on when you might be able to take a look? (This is the last remaining issue that's holding us back from having our Alpha approved, so we're keen to get a resolution!). 

If you won't be able to look at it in the next couple of days, could you give me some pointers on how I can go about fixing it?

Thanks,

Rob.

Progress! The FlowMachine is now destroyed correctly, but the FlowMacro, and anything it links to, is not. 

Using the same test project as yesterday, if at the end you search for PlayableDirector you'll find that it still exists. The problem seems to be that OnDestroy is never called on the Macro, so it never removes itself from the list of available dependencies in Serialization. Here's the path to root for the PlayableDirector: