EDIT Jun 15: The 4.8 release notes (way down, in the Core section) say the following about this:
Hot reload uses special empty auto-generated constructors to obtain virtual table pointers from UObjects and to avoid re-constructing subobjects when creating temporary objects after loading the recompiled DLL but before the classes have been regenerated. This implies the requirement that all member variable types are default constructible.
The signature of the new constructor is UMyClass::UMyClass(FVTableHelper& Helper) and it can be manually defined in the header file to initialize all member variables that are not default-constructible
Auto-generation of the new constructors can be disabled by defining WITH_HOT_RELOAD_CTORS macro to 0 and setting [Core.System] UseVTableConstructors to False in BaseEngine.ini.
Note that disabling this feature may result in crashes when performing hot reload.
So it's confirmed - either disable hot reload ctors or add this special ctor to your class members as needed.
The message of the commit which introduced this problem contains indications on how to workaround it:
Date: 2015-03-02 11:44:04
UE-10111: Hot Reload crash with Scene Component tied to Actor class
We've changed the way vtable ptr are obtained for UClasses. Right now we use special empty constructor to get it, so we don't have to use normal one which was causing troubles. This special vtable helper constructor is generated automatically for most cases, but sometimes it's not possible (e.g. no default constructor for members types). In such case there is a possibility to override that generated constructor and write a custom one. The signature is UCustomClass::UCustomClass(FVTableHelper& Helper) and it needs to call base class'es constructor with the same parameter. Please do not use these constructors for anything else. There is no guarantee the object will be in correct state after calling this.
You can still disable this functionality if something breaks, just set WITH_HOT_RELOAD_CTORS to 0.
[CL 2466152 by Jaroslaw Palczynski in Main branch]
So if I read the message correctly, my example above would be fixed by adding a ctor to AMyActor:
class FAIL48_API AMyActor : public AActor
// adding this ctor fixes the problem:
m_member(2) // and here you can initialize your members
My engine is compiling, so right now I can't confirm that doing this solves the problem.
[EDIT May 28: Just confirmed - adding the constructor fixes it.]
May 28 '15 at 11:51 AM