Anyone had this… I’ve got some code in a plugin I wrote. I’m trying to debug one of the components in it. But when I add a breakpoint in the class, the stepping doesn’t work at all. Usually this is the PDB file being a different version, but I’m not so sure. Anyone know where the PDB files are output for plugins? How do I verify the PDB is the same as the DLL being loaded? Is there a setting in UBT or some such?
Thanks for any info.
Just to reply to myself, in VS, its debug->windows->modules and it looks like the pdb file is actually loaded and the right one. Which leaves me a bit stumped to be honest. Got code in a tick function that calls another function, the tick gets called but trying to single step into the other function thats called just doesn’t work and that other function never hits a breakpoint set in it. HIGHLY annoying 
Ohhh my. Its one weird thing after another this week. So I’ve got a component with TickComponent being called. All it well and good, apart from the functions called within the TickComponent do not get called! I mean the TickComponent gets called, I set a breakpoint in there and it breaks. But when it steps to the function call of another function I want to tick, it literally just passes right over it!
I just don’t get how a compiler can get quite so screwed up
anyone got any ideas how to debug code not calling code even though the code is obviously there?
Worth putting in some log output to check whether it’s flat out not being called, or if it’s just the debugger not stepping into it due to code optimizations. Could well be the latter if you’re in Development configuration, or even if you’re in Debug configuration but your plugin is engine level as opposed to project level.
If it ain’t being called, then that’s probably UBT ******** up -> full clean plus remove intermediate folders (project + plugin) and regenerate project files time!
Does the Auto’s/Local’s window say that it was optomised out?
I’ve had that with variables under “development editor”.
HTH
I have this issue occasionally (both with UE4 and other projects). It seems to be caused by VS thinking your PDB files are out of date (or newer) compared to the executable you’re trying to debug. A full clean and rebuild normally fixes this for me.
So on further inspection, when I moved my plugin code to another project it compiles and runs as expected. So I went back to the original codebase and spotted this little fella:
[Adaptive unity build] Excluded from TacticalAI unity file: AITacticalPerceptionComponent.cpp
Which suggests that something is specifically happening with that file (which is the file I’m having a problem with in debug), any info on what causes this exclusion and if there’s a way to change that? Anyone understand exactly what and how this unity build stuff is setup? Or a way to affect which files are excluded or not?
In that case it would be very strange indeed if a full project + plugin intermediates clean and rebuild didn’t fix it. Definitely looks like it’s a case of UBT getting itself in a muddle.
I disable unity builds for development, less issues and faster iteration for me. You can do it by opening Engine/Saved/UnrealBuildTool/BuildConfiguration.xml and adding <bUseUnityBuild>false</bUseUnityBuild> within the <BuildConfiguration> element.
Another thing I’ve spotted:
47>D:\Ground Branch\GroundBranch\Plugins\TacticalAI\Source\TacticalAI\Private\Perception\AITacticalPerceptionComponent.cpp : warning C4653: compiler option ‘Optimizations (one or more of /Oawstgp[y]) or debug checks (one or more of /GZ, /RTCcsu)’ inconsistent with precompiled header; current command-line option ignored
Which suggests to me that something is causing this particular file to compile with different compiler options than the others.
so here’s a fun one… I added the line:
OptimizeCode = CodeOptimization.Never;
To my module’s build.cs and now the code works as expected. So clearly something is causing specific files within that module to be built with optimisations on, or at least the incorrect debug settings. Why specific files? I will investigate further!
The file you mention isn’t part of the engine code, so I can’t check what it’s doing. But it’s definitely possible to selectively enable or disable certain optimizations at the file or even function level. With MSVC you can do
#pragma optimize("", off)
<insert long problematic function causing a compiler crash here>
#pragma optimize("", on)
If you are using precompiled headers (which UBT does by default) and the #pragma is at file scope, that will generate the warning you see because the PCH optimization level doesn’t match the optimization level of the translation unit. (Though in my experience it is usually an error, but that might be because UBT defaults to warnings as errors). If and how all of this would affect PDB generation depends on the compiler. It’s certainly plausible that a compiler could generate mismatching debug symbols if it isn’t aware that the code generator switched to a different optimization level at the current scope. That’s just a hunch though, I haven’t seen this happen myself.