C++ Transition Guide for 5.4

Development Programming & Scripting
21

Hi! After the little adjustments needed to migrate my project to 5.4 I finally managed to have everything functioning perfectly in editor and packaging without issues. A problem though arises the moment I launch my packaged build. A map gets loaded and immediately after the game crashes. This is what I get from the crash report:

Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0xffffffffffffffff

Theseus_Win64_Shipping!FPakAsyncReadFileHandle::ReadRequest()
Theseus_Win64_Shipping!TScriptContainerIterator::operator bool()
Theseus_Win64_Shipping!UE::FPackageResourceIoBackend::Resolve()
Theseus_Win64_Shipping!FIoDispatcherImpl::ProcessIncomingRequests()
Theseus_Win64_Shipping!FIoDispatcherImpl::Run()
Theseus_Win64_Shipping!FRunnableThreadWin::Run()

Packaging in DebugGame yields the same result, and I canā€™t get any more useful info. Even by using VS and ā€œattaching to a processā€ to the running game I donā€™t get any reference to the game code. I also tried to disable ā€œUse Pak Fileā€ in the packaging options as what crashes seems related to a function that reads the Paks : FPakAsyncReadFileHandle::ReadRequest() ā€“ but I get the same exact crash.

Any help would be greatly appreciated, even in just how could I simply proceed to debug this!

Thanks!

1 Like
22

Took a week, but found the issue. Turns out that thereā€™s been some significant upgrade to Metahumans ā€“ the Metahumans I have in my project are now considered ā€œlegacyā€ and need to be re-exported from the Metahuman editor. Loading a map with the updated metahuman doesnā€™t indeed cause that crash anymore.

1 Like
23

I have the same exact error in 5.4.4. Havenā€™t found a solution yet. If it helps, this only appeared for me after I updated a plugin that now uses

#include "Chaos/TriangleMeshImplicitObject.h"
24

By the way, GetObjectW / GetObject probably indicates a windows.h name collision issue

25

It seems like youā€™re looking for a transition guide to C++ version 5.4, but C++ versions arenā€™t typically numbered in that way. C++ versions are usually denoted by the year of their release (e.g., C++98, C++11, C++14, C++17, C++20, and the upcoming C++23). If youā€™re referring to a compiler (such as GCC 5.4) or a specific framework or library version, I can help with that as well.

26

Migration is driving me crazyā€¦ While trying to solve another engine bug in 5.3, I just checked the migration to 5.4 again. Just like before, I resolved all issues related to the migration from 5.3 to 5.4, except for the one mentioned above. This time, the migration was successful without any changes from my end.

27

Resolved this. I was including asio, a header-only library which itself includes windows.h, without properly wrapping Unrealā€™s windows platform type enable/disable code around it.

I had got confused between windows header inclusion and temp-reenabling-windows-platform-types. I think this lead to a situation where a windows.h inclusion without the wrapper or allow/hide includes got through to unreal C++ code, causing platform types to conflict in name with unreal types.

Windows header inclusion in unreal:

#include "Windows/WindowsHWrapper.h"

Wrapping a header which needs to use Windows platform types (which I had missed):

#include "Windows/AllowWindowsPlatformTypes.h"
#include "Windows/AllowWindowsPlatformAtomics.h"
#include "asio.hpp"
#include "Windows/HideWindowsPlatformTypes.h"
#include "Windows/HideWindowsPlatformAtomics.h"
28

I could not migrate to 5.4.1, but to be honest, I did nothing to migrate to 5.4.4. So I donā€™t know what actually caused the issue ))

29

This issue is driving me crazy. Iā€™ve run into this compilation error again. I spent a lot of time realizing that itā€™s the same issue as before, and even more time trying to fix it once again. The funny thing is, Iā€™ve spent months creating functionality, adding many complex classes, and everything worked fine. But today, I added a simple UObject class with a basic struct, and suddenly, this error is back.

It seems that the order of inclusions has changed, and once again, Iā€™m hitting the GetObjectW problemā€¦

I havenā€™t been able to find a proper solution to fix it. I donā€™t use any third-party libraries that might include windows.h, so I canā€™t blame that. But as I donā€™t currently have plans to migrate further, I decided to create a small, admittedly dumb, fix directly in the source code.

In ImplicitObject.h I created a duplicate of the GetObject method and renamed it GetObjectFu...gFix.
Then, I used this new method in all three places of UnwrapImplicit. And just like that, the problem disappeared. =\