While I can get into a debugger using UE 4.13 and XCode (on OSX Sierra 10.12 and Xcode 8.1) it’s pretty much useless, since most of the data has been optimized away in the code I’m stepping through.
I’ve rebuilt UE and my project in Debug Editor - at least, I think I have - but that does not seem to change the behavior. I’ve also tried pragma optimize ("", off) around the function I want to debug – but still no dice.
I’m worrying about this line in the UE docs:
When building in Xcode, you are only compiling the game project, not the Editor.
Does that mean that, no matter what I do, I won’t be able to step through editor code (as opposed to game code) properly?
If you’re building debug editor from source you should be able to step through its code just fine. Perhaps you built it, but your project’s scheme is set to use Development Editor, not Debug Editor, or you set a custom executable? Try this in Xcode:
- In Product->Scheme menu select your project
- Use Product->Scheme->Edit Scheme… to open scheme editor
- In Info tab for Run make sure the Build Configuration is set to Debug Editor and Executable is not set to anything custom (by default it should be YourProject.app with application icon)
- Close the scheme editor and use Product->Run to build and run the project
This should build the editor in debug (if needed) and your project’s files needed by the editor, then launch it.
This didn’t seem to fix it for me. Is it necessary to get lldbinit files?
No, you shouldn’t need to edit .lldbinit
What part of the editor are you trying to debug exactly? Maybe you’re stepping into some third party library code?
Really basic stuff. I made a plugin which loops over FAssetData objects from the asset database and logs some statistics to a CSV file. The code works fine – and I can step through it fine – but the XCode’s view of the locals is pretty useless – an FName, for example, reports its index value but not the actual string representation of the name; an FString will tell me how many characters it has, but not what they are, and so on.
Ah, that’s different from variables being optimized out. And yes, in that case you do need to have certain entries in .lldbinit
For Xcode (or rather the lldb debugger Xcode is using) to display custom Unreal data types nicely we have Python script - Engine/Extras/LLDBDataFormatters/UE4DataFormatters.py
When we generate UE4 Xcode project we add an entry to .lldbinit that makes lldb use this script, but the code that add this entry is not very clever. If you already have such an entry in there, but the path is invalid (for example because you moved the engine to some other location), it won’t update it.
Try opening your .lldbinit file and see what path you have in a line like this:
command script import "/Volumes/Data/Projects/UE4-Dev-Platform/Engine/Extras/LLDBDataFormatters/UE4DataFormatters.py"