It seems to crash on or after “scalable_free(Ptr)”
I suspect it has something to do with my own DLL which uses its own memory allocator.
I am in the process of trying some stuff to figure out a better callstack but in the meantime if a dev could shed some light what could be going wrong I would be grateful.
I have my own DLLs that internally define allocators for their own memory management.
In my case though I instantiate one of my classes in the UE plugin.
cMyClass* pMyClass = new cMyClass();
pMyClass->DoSomething();
and after a while I get the crash (I am saying after a whi;e because there is a loop that keeps it “doing something” for a maximum of 8 seconds" but it doesn’t even last 8 seconds it almost immediately crashes but it crashes on a line that has nothing to do with a “delete”
if(bWasSuccessful) ← crash
{
//do bla bla
}
my callstack looks very strange as well … as in it looks correct up to the line
containing “if(bWasSuccessful)” but then it has the MallocTBB
cMyClass is a pure C++ class from my own framework (independent of Unreal - so no UObject).
I think I know what the problem is.
I allocate the object in unreal (hence it uses the unreal allocators) but when calling some other methods , I believe it deletes the object from within the DLL (I am using zeroMQ for my networking protocols - pMyClass in this case is actually a “message class”. And I think the zeroMQ send actually implicitly calls delete on the message you have sent ).
Verifying now if creating a factory class called on my DLL will fix the problem.
(basically avoid calling “new” from withing unreal of my DLL classes.)
okay so I was able to verify my theory that the issue arises indeed because the pointer/memory is deleted within my DLL framework. It gives me an opportunity to improve all my object creation and move it over to factories which is better anyway from a design point of view. Thanks anyway for your prompt interest.
EDIT : actually the problems seems to still persist in one way or another.
it seems like the crash has returned in a different form.
I converted my whole framework to be in a DLL.
I invoke some functions from within my unreal engine 4 plugin that I am writing. (hence a DLL on its own).
if I use my framework as a DLL and allocate all my objects within the DLL then unreal crashes in FMallocTBB:Free(void* Ptr).
it is strange because on the line it crashes it is’t calling any destructor or anything that would make me think there is a delete call going on. So my guess is that unreal tries to garbage collect my object (its a straight c++ object that i am being given by my framework). I am not even using my own allocators anymore right now just pure “new” and “delete” within my framework.
if I make my framework a static library instead then my unreal game doesnt crash but it looks like my object is being garbage collected after ending my current scope of code. So If i invoke my code again then the object that i retrive within my framework is now NULL (its a singleton inside my framework… )
I feel like I need some help from an engine dev here who could help me analyze my problem.
MyManager* pManager = MyFramework::GetManagerInstance();
//at this point if I put a watch on pManager,it has a valid pointer and everything looks fine
//then couple of lines down
pManager->DoSomething();
//outside the pointer is still valid and looking good, then stepping inside the method
`` and suddently the “this” pointer is NULL
here the implementation within my framework code (compiled as a static library)
MyManager* GetManagerInstance()
{
MyManager* pManager = MyManager::Get();
return pManager;
}
and the Get is declared as a simple singleton
class MyLibExport MyManager
{
public:
static MyManager* Get();
/blablabla
private:
static MyManager* mpMyManagerInstance;
};
and implemented as
MyManager* MyManager::mpMyManagerInstance = NULL;
MyManager* MyManager::Get()
{
if(!mpMyManagerInstance)
{
mpMyManagerInstance = new MyManager();
}
return mpMyManagerInstance;
}
First thing I’d check is what “new” and “delete” are actually doing in your DLL by stepping into them with the debugger. Hopefully, they end up calling FMemory::Malloc/FMemory::Free. However, a crash in MallocTBB::Free suggests that somewhere a bad pointer is getting through and the fact that when your framework is statically linked this crash goes away also suggests some sort of DLL linking issue.
Hopefully, if you discover the cause behind your crash the other issues you’re having will go away so I’d focus on fixing that first…
Not really, at the moment i just statically link my framework. Eventually i would like to go back to use it as a DLL but for the time being I had to move on.