Stack overflow problems

Development Programming & Scripting C++
1

Oh boy. I have been trying to solve this for a week but I’m just not experienced enough, so I need some insight! I have a ton of questions, so sorry in advance for the long post but I need to fill some gaps.

This is the situation:

  1. I have an SDK that my plugin accesses in the form of an external DLL
  2. I’ve got as much separation between UE and the DLL as possible. The DLL manages its own reference counting and garbage collection, etc.
  3. Linking them up are some straight C++ classes without any UE macros wrapped around them (except for classes that need to tick, import, etc.)

I thought this was a nice clean solution but now I’m wondering if I shouldn’t have been making my linker classes UE-aware so that they can be managed properly.

Currently I’m experiencing a stack overflow. it is highly consistent and easily replicable but I can’t find the cause of it.

  1. If the DLL tries to write to the debug output, it crashes with a stack overflow
  2. If I comment out that code, UE logging crashes with a stack overflow instead!
  3. It is always the exact same logging attempts although they’re not the culprits. If I comment out enough code the problem goes away but that hasn’t helped me figure out what’s causing it, I might still have the problem and just not be triggering it.

It’s been suggested that some other thing somewhere else in my code may be going out of bounds and causing this. I’ve only used TArrays, etc, but they’re holding UE-unaware plain classes. For example, I’m using a recursive node tree so I instantiate new objects this way:


MyChildren.Add(Node(arg1, arg2, arg3, this, arg4)
  1. Someone suggested this means they’re unmanaged and not benefiting from reference counting and can possibly cause the overflow.
  2. Should I convert my linker classes to be UE-away, eg. Converting MyNode class to UMyNode and wrapping it in the right macros?
  3. How should I be instantiating objects like this? I assume CreateNew() isn’t necessary, right?

If the answer to the above is YES, good! I’ve already started doing it!

So my constructor (as seen above) has a bunch of input arguments. UObjects typically have that parent-call and superobject, etc. Does this matter? Do I need it?

Do I need to inherit from anything in my class, say UObject?

When is it appropriate to put a UProperty() on something? If I’m just tracking say a scalar, does it need UProperty? Or is that only for references and pointers that I want counted?

I also want my nodes to know who their parent is, so in the constructor arguments I also include “this”. Since switching it to being UE-aware non-static functions are now saying that they’re static and “this” can’t be referenced. How do I reference the parent object?

2 

1>c:\unrealengine\projects\octaneue4importer_410\plugins\octanerenderplugin\source\octanerenderplugin\private\Octane/OctaneNode.h(41): error C2338: You have to define UOctaneNode::UOctaneNode() or UOctaneNode::UOctaneNode(const FObjectInitializer&). This is required by UObject system to work correctly.

Cool, that answers my question about constructors.

What’s the best way to pass in all of my arguments? Do it outside of the constructor and use an init function, or is there a more elegant way?

Edit: Use init(): 4.7 How do I actually pass parameter's in the new constructor format? - C++ Gameplay Programming - Unreal Engine Forums

3

So I finished converting my node class to a UObject child class and it’s working much better. Another stack overflow occurs but I can see that I have some cyclic recursion going on, so that sort of makes sense and should be an easy fix. The program gets way beyond where it was failing earlier.