New issue
Advanced search Search tips

Issue 756131 link

Starred by 4 users

Issue metadata

Status: WontFix
Owner:
Closed: Jun 20
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug

Blocking:
issue 636111



Sign in to add a comment

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

Project Member Reported by jam@chromium.org, Aug 16 2017

Issue description

In NavigationControllerImpl::Reload, |this| similarly gives "Error reading register value."

Another example: NavigationControllerImpl::NavigateToPendingEntry does have |this| working, however entries_ doesn't show anything, just "{ size=??? }"
 

Comment 1 by jam@chromium.org, Aug 16 2017

(same gn args as in  bug 755213 )

Comment 2 by r...@chromium.org, Aug 16 2017

Owner: zturner@chromium.org

Comment 3 by r...@chromium.org, Aug 16 2017

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

Comment 5 by r...@chromium.org, Sep 14 2017

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?

Comment 6 by jam@chromium.org, Oct 20 2017

Status: Assigned (was: Untriaged)
@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???

Comment 7 by jam@chromium.org, Oct 20 2017

btw I tested on latest trunk with a clean build.

Comment 8 by thakis@chromium.org, Oct 20 2017

Blocking: 709690

Comment 9 by r...@chromium.org, Oct 25 2017

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.
nav-frame-entries.png
26.3 KB View Download

Comment 10 by r...@chromium.org, Oct 26 2017

Owner: r...@chromium.org
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.
nav-frame-msvc-goma-fastlink.png
35.5 KB View Download

Comment 11 by jam@chromium.org, Oct 26 2017

@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.

Comment 12 by dxf@google.com, Oct 26 2017

We're targeting M65 for the switch to LLD.

Comment 13 by r...@chromium.org, Oct 26 2017

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.

Comment 14 by dxf@google.com, Nov 23 2017

Blocking: -709690

Comment 15 by r...@chromium.org, Nov 27 2017

Summary: Visual Studio may fail to visualize variables when using /debug:fastlink and clang or goma (/Z7) (was: (debug build) member variables aren't showing in MSVS)
Re-titling.
Status: WontFix (was: Assigned)
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.

Sign in to add a comment