Avoiding garbadge collection for the whole class

I have 2 blank classes. They controlls bullet and bullet system. But they are crashing whole game in the worst way, because somewhere there is garbadge collector is “having fun” by destroying some data. In case i don’t know why and where i need to make GC don’t get care about these 2 classes. How to disable garbadge collection for custom class? (class uses project api anyway)

P.S. Forget to tell what is happening. I started level - all is fine. I’am started shooting, using my bullet system, some time it goes OK. After 1-30 seconds it crashes with random adresses but same reason: unable to write. It happens with FMemoryTBB, scalable_alloc, FMemory::Realloc, FMemory::Malloc and somewhere msvcrt lib where no source code avaliable. So even if I shave my source, it will not give you much enougth info. But I sure about GC - it is having fun with my class.

As long as anything has an reference to an object (starting from level), it should not get destroyed…

By coincidence, I read about it somewhere:

UE4’s garbage collection can really
catch you when you least expect it.
Anything derived from a UObject (which
is almost everything that’s not a
value type), if instantiated during
play, will be GCed after the timeout
defined in the relevant .ini file (for
me, 60 seconds). The way to fix this
is to mark any references to such
objects with a UPROPERTY() macro in
the line above their declaration if
they’re a class member.

I guess you need to investigate this (I have no knowledge in this area, google it yourself)

You can implement your own reference counting by implementing AddReferencedObjects(UObject* InThis, FReferenceCollector& Collector) . In this static function, you would use Collector to manually increment references of objects referenced by InThis.

Also, you can call AddToRoot/RemoveFromRoot to disable/eneable GC on UObject.

I’m fairly certain this is the answer. Another alternative is to just not use unreal derived classes if you don’t want things to be garbage collected and manage the memory yourself.

This is custom classes, i can’t make them as UPROPERTY()

It might help to see a simple version of your code, because if your object is not a UObject, then Unreals GC won’t touch it.

I’ll give you whole code :slight_smile:

A MCVE would be more help… Specifically, what data do you think is being GC’d

Well, i didn’t gave you two more classes, because i don’t think, that they causes the problem, but don’t know where exactly crash happens, because it happens RANDOMLY while i playing level and shooting (see BulletSystem::MakeBullet() - it creates bullets)… Wait a minute, one thing i didn’t checked is UParticleSystemComponent (class BulletTrail if i remeber properly). Last time before it started happening i erased UPROPERTY() in declaration.
Upd: made UPROPERTY() class UParticleSystem * ps; - didn’t helped…

Make your “BulletSlave” pointer in “BulletSystem.h” a UPROPERTY().

Also: Where is your BulletSystem being initialized?

It is impossible to make BulletSlave as UPROPERTY, because it is “Unrecognized type”, i tried though.
BulletSystem is being initialized (kinda) in BeginPlay method of main character class using function MakeSystem in BulletSystem. I’am not using usual initializer… almost.

Ok. I’m not certain about this, because your raycast function and the function that is using it are really messy, but you are doing a lot of totally unnecessary deletes all over your code of referenced objects that you are not responsible for, and that is probably your problem.

What I would do is:

  1. Trash most of your raycast function. Do not use pointer style arrays. Store in TArray. Append both your line trace results into that TArray, then call Sort on it with your own sorting predicate.

  2. Use Unreal to it’s strengths so you can avoid your weaknesses. You are totally overusing the heap in some very dangerous ways. Way too many news, and way too many deletes. I can almost guarantee that it is not Unreal’s GC that is messing you up. Looking at your code it is almost certainly you deleting something you shouldn’t be. There’s no reason to create a custom type to pass around FHitResults when you can just pass FHitResults.

  3. Make your BulletSlave a UObject. If you want it to be ticking every frame, you’ll have a much easier time making it a tickable UObject because UE4 will multithread tickable game objects.

  4. ENCAPSULATE YOUR LOOPS. This may not be your problem right now, but it’s easy to add some {}s and it will make your code SO MUCH EASIER to read and so much more secure going forward.

  5. A for loop with nothing in its expressions is just a while loop.

I almost guarantee you the problem is with your raycast function or in your SystemTick or somewhere else, because you are doing so much stuff that’s totally dangerous. I have a hard time believing UE’s GC is the problem with the lack of attention to detail with some of your nested loops and haphazard allocations/deallocations.

You also don’t call the parent constructor in your BulletSystem.cpp

Well, I asked this question, because GC tried to delete data, that had already has been deleted manually. What it means? I means that I, as Idiot, created my own destructors…
And there no need to avoid GC if you make everything right. Manually deleting AActor will left garbage. It better to left this work for default ~UObject(), what GC actually uses.