Issue 756131: Visual Studio may fail to visualize variables when using /debug:fastlink and clang or goma (/Z7)

(same gn args as in  bug 755213 )

I'm unable to reproduce this.  Can you try deleting the PDB and EXE/DLL and rebuilding and see if the problem goes away?

Can anyone reproduce this, or should we close it out?

Also, in general, how should we make sure VS is attached to the right process to break on the function in question? Run chrome.exe with --renderer-startup-dialog --no-sandbox?

@rnk: in this case, this is code in the browser process (i.e. the "browser" in content/browser/frame_host/navigation_controller_impl.cc). So you can just run chrome.exe


The first part of this is fixed (|this| in NavigationControllerImpl::Reload). However the second part is still broken; NavigationControllerImpl::entries_ just shows???

btw I tested on latest trunk with a clean build.

I reproduced the issue, and it looks like something's wrong with the evaluation of the std::vector visualizer. As you can see in the screenshot, it's saying "Attempt to divide by zero". I tried making a reduced test case with a std::vector<std::unique_ptr<Foo>>, but it visualized just fine, so I'll have to keep digging.

The only division that comes to mind in the vector visualizer is from the pointer subtraction, which divides by sizeof(std::unique_ptr<NavigationEntryImpl>). That type has the correct size, though.

I turned on the natvis diagnostics, and I got these interesting messages:

Natvis: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\Packages\Debugger\Visualizers\stl.natvis(284,37): Error: identifier "_Mypair" is undefined
    Error while evaluating '_Mypair._Myval2' in the context of type 'content.dll!std::unique_ptr<content::NavigationEntryImpl,std::default_delete<content::NavigationEntryImpl> >'.
Natvis: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\Packages\Debugger\Visualizers\stl.natvis(283,4): Ignoring visualizer for type 'std::unique_ptr<content::NavigationEntryImpl,std::default_delete<content::NavigationEntryImpl> >' labeled as 'std::unique_ptr<*>' because one or more sub-expressions was invalid.
Natvis: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\Packages\Debugger\Visualizers\stl.natvis(274,37): Error: identifier "_Myptr" is undefined
    Error while evaluating '_Myptr' in the context of type 'content.dll!std::unique_ptr<content::NavigationEntryImpl,std::default_delete<content::NavigationEntryImpl> >'.
Natvis: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\Packages\Debugger\Visualizers\stl.natvis(273,4): Ignoring visualizer for type 'std::unique_ptr<content::NavigationEntryImpl,std::default_delete<content::NavigationEntryImpl> >' labeled as 'std::unique_ptr<*>' because one or more sub-expressions was invalid.

That's not really related to visualizing std::vector<std::unique_ptr<...>>, but it might be related.

I tried relinking content.dll with normal /debug instead of /debug:fastlink, and if I do that, the issue goes away. I feel like we're running into some kind of fastlink limitation here.

Deleted: nav-frame-entries.png 26.3 KB

	nav-frame-entries.png 26.3 KB View Download

I rebuilt with MSVC, goma, and fastlink, to attempt to match the exact recommended clang gn config. I used these gn args:

is_debug = true
symbol_level = 2
win_linker_timing = true
is_component_build = true
is_win_fastlink = true
enable_google_now = false
enable_nacl = false
is_clang = false
use_goma = true
goma_dir = "C:\goma\goma-win64"
target_cpu = "x86"

MSVC has the same visualization problem as clang, see the attached screenshot.

So, this isn't a bug in clang's debug info output, it's a bug somewhere in the fastlink ecosystem. It's hard to say if it's a bug in the linker or the VS native debug engine. I suspect we aren't "holding it right" because using goma implies /Z7 but the default is /Zi (type server PDBs). Still, it would be nice to file a smaller reproduction of the issue.

I think we should consider removing the blocker label from this bug if this isn't a widespread problem. LLD already exists and writes correct PDBs twice as fast as the VC linker. I'd rather spend time on the open source linker than finding workarounds for VC tools. Please let us know if these kinds of vector visualization problems come up again.

Deleted: nav-frame-msvc-goma-fastlink.png 35.5 KB

	nav-frame-msvc-goma-fastlink.png 35.5 KB View Download

@rnk: when do you expect that LLD could be turned on by default?

One issue is that now when debugging it's impossible to see these entries, which was very useful in the past. The comparison with MSVC is not quite apples-to-apples, since without clang building locally is faster without goma, so fast link didn't need to be used. With clang, I need to use goma or else it's much slower to build, and I need fast link as well.

We're targeting M65 for the switch to LLD.

Right, I'm aware that clang essentially requires the user to use goma+/debug:fastlink, so this is important. I just want to set expectations that this isn't going to be easy to fix, since MSVC has the same bug. I'd like to wait and see for a bit how often these visualizers fail in practice, and ask the question, if we can't work around this fastlink bug, should we keep the switch anyway?

In the meantime, I reached out to someone at Microsoft about the bug in MSVC. They were interested in getting a reproduction and seemed willing to build Chromium. Ideally I'd get them a reduced example, but it may be an issue that only comes up with large fastlink PDBs, in which case they'll need a full Chromium build.

Re-titling.

We've stopped recommending that developers user /debug:fastlink. LLD's regular /debug is faster than MSVC's fastlink PDBs, and it works with goma.