Rider opening incorrect Unreal Engine .cpp file when step-debugging

As an additional piece of info. If I close rider, rename the folder of the original source build for the engine to something different (e.g. D:\UnrealEngine-Slime → D:\UnrealEngine-Slime_blahblahblah) and restart rider, everything now behaves correctly. And all debugging breakpoints, variable inspection, and execution marker show up in the single teal tab.

I do NOT consider this a solution, as I don't want to have to rename directories to work around this issue. 

Is there somewhere where some search order for source is set that I need to change so the uproject's associated 5.5 version is used before the 5.5 source folder the engine was built from is used? Right now those source trees match up, but in the future i might be working on source engine patches and they will diverge from the engine the project is executing against

Hello Jon,

Thank you so much for such a detailed description of the problem. This is actually not a bug, but a debugger by-design behavior:

When you build a sample project, the generated output is .dll (the built application/library itself or a module) and a .pdb file (program database = symbols file for debugging). As a result of build process, exact absolute paths to source files are being embedded into .pdb file. This is done for the debugging purpose. Having this information the debugger can map a breakpoint set by a person in source file to the instruction in a module, so that it can suspend execution when instruction pointer reaches corresponding instruction.

Since you ‘copied’ the engine folder, the resulting engine directory (D:\UnrealEngine\UE_5.5_SLIME) contains built .dll with .pdb where .pdb points to original source files, same as .pdb in the origin directory (D:\UnrealEngine-Slime).

That is what happening: 

• Rider passes file path, line number and hash to the debugger;
• Looking into .pdb, the debugger searches for an entry with matching file name. As long it is there, the file exists on machine and its hash matches with the one in what user placed a breakpoint, lldb resolves the breakpoint to this exact source file (the one with original path);
• When debugger hits the breakpoint, it sends corresponding data to Rider, that displays it: opens exact file (by path, received from debugger) and shows the place of stop;

In a scenario when source files with origin paths doesn't exists on machine:

• When your colleagues consumes the build you built;
• Same as if you make the original source paths to become invalid (by renaming/replacing the origin directory D:\UnrealEngine-Slime upon building and copying it to another directory);

The debugger falls back to another behavior: it uses the target.source-map setting to remap the path to source files (that is expected to be by path written in .pdb) to corresponding directory taken from Rider-internal project model (built by Rider for its internal use). However, by lldb design, this hack starts working only if the origin source files doesn't exist on machine.

That is why it works in the mentioned scenarios and that is why it doesn't affect your colleagues. This behavior is observed on your build machine as long the paths to source files written in .pdb are valid.

The most proper approach to avoid this issue is to re-build the engine upon copying (zip/unzip): Open D:\UnrealEngine\UE_5.5_SLIME\UE5.sln (or Default.uprojectdirs, depending on your current approach).

Another option you have already discovered: rename/replace the originally built engine, but I agree this might be an inconvenient approach to follow.

Finally: As long as you wish to dog food the experience of the rest of the studio, you could consume the built engine same as your colleagues: on another machine that has no originally built binaries. I agree, this might be treated as overkill. The easier solution is to rename the origin engine directory before you go dog food the unzipped version of the engine. You might want to script the rename operation (rename and rename back) in some way, for ex:

build_mode.bat
mv D:\UnrealEngine-Slime D:\UnrealEngine-Slime_inProgress;
:: or using extra helping name:
:: mv D:\UnrealEngine-Slime_distributed D:\UnrealEngine-Slime_inProgress;
:: or temporarily pushing the built engine directory to stage directory
:: mv D:\stage\UnrealEngine-Slime D:\UnrealEngine-Slime
:: then open D:\UnrealEngine-Slime\UE5.sln

dogfood_mode.bat
mv D:\UnrealEngine-Slime_inProgress D:\UnrealEngine-Slime
:: or
:: mv D:\UnrealEngine-Slime_inProgress D:\UnrealEngine-Slime_distributed
:: or
:: mv D:\UnrealEngine-Slime D:\stage\UnrealEngine-Slime
:: then open the project that targets D:\UnrealEngine\UE_5.5_SLIME engine

Last, we agree there might be an improvement around this behavior. However, we haven't seen such a complaints earlier, thank you for bringing this case to us! As of now I registered this feature request on our tracker: RIDER-126296 Consider prioritizing source files in project model over source files which paths are specified in PDB

We would appreciate it if you could upvote it to demonstrate your interest.

Have a nice day!

Thanks for the detailed explanation and possible work arounds! Now that I understand what's happening, for now I'll just rename the directory and should tinkering with the engine become more frequent I'll set up something better.