Why are C++ debug symbols mismatched when generated in the same Visual Studio solution?

Viewed 200

Something is wrong with my Visual Studio 2019 project configuration and I have run out of ideas to check. I have 3 native C++ shared libraries (A, B, C) that all sequentially stack on each other. B depends on A. C depends B. I then link all 3 to an executable. So the final stack looks like A->B->C->Executable. All of the libraries and executable live within the same Visual Studio solution. All of the code is mine. The solution file was generated by CMake.

I can set breakpoints and debug into A, B, and the executable just fine. I cannot step into library C because the symbol file will not load. The Modules window says it "Cannot find or open the PDB file." The search path does include the project output folder. When I manually attempt to load the autogenerated library_c.pdb file I see a pop up error stating "A matching symbol file was not found in this folder."

I have tried deleting everything and recreating the environment from scratch. I have compared all the project settings between library C and the other debuggable libraries but found no discernable differences. My internet searches all say how to manually load symbols or indicate that the error is because the symbol don't match. I have not found any that suggest how or why the autogenerated pdb would not match the corresponding lib or dll when built.

Given this situation, what would you investigate next? What could cause the generated symbol file to be mismatched?

EDIT: drescherjm suggested I double check timestamps. Windows Explorer lists the "Date modified" as being identical. However, if I right click on each file and open properties I get an interesting abnormality. The "Created" timestamp of the good working files all have a date and time (HH:MM:SS). The bad library_c.pdb lists a date with no timestamp. Instead of a timestamp it says "XX minutes ago." I'm not sure what this means but it is a difference.

1 Answers

The CMake file for library C (called foo_client here) has this snippet.

add_library(foo::foo_client ALIAS foo_client)
set_target_properties(foo_client PROPERTIES EXPORT_NAME client)

The executable's target name in CMake is foo_client_exec. For a reason unknown to me this triggers a corrupt foo_client.pdb file. By using dbh I dumped all the source files (dbh foo_client.pdb src) referenced in the .pdb file and confirmed the list was missing everything from the foo_client library. However, it somehow referenced files from the executable. Let me repeat that oddity to emphasize it. The exectuable's files were somehow referenced in library's .pdb., foo_client.pdb. I have no idea how the chain of binaries could be propagated backwards from executable back into the library.

If I renamed the executable to anything that did NOT start with "foo_client" as a prefix then the .pdb file was generated correctly and only referenced the foo_client files. It appears that Visual Studio 2019 and/or CMake 3.15 was doing some kind of naming pattern match that caused the source files of the executable to replace the libary's files in the generated .pdb.

Despite the corrupted .pdb file the library performed without issue when linked into any executable. Whatever the root cause of the problem is it appears to be isolated to the generation of the .pdb file. Everything else works as normal as far as I can tell.

Related