Issue 756131: Visual Studio may fail to visualize variables when using /debug:fastlink and clang or goma (/Z7) |
|||||||||
Issue descriptionIn 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=??? }" Aug 16 2017,
Aug 16 2017,
Aug 16 2017,I'm unable to reproduce this. Can you try deleting the PDB and EXE/DLL and rebuilding and see if the problem goes away? 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? Oct 20 2017,
@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??? Oct 20 2017,btw I tested on latest trunk with a clean build. Oct 20 2017,
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. Oct 26 2017,
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. 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. Oct 26 2017,We're targeting M65 for the switch to LLD. 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. Nov 23 2017,
Nov 27 2017,
Re-titling. Jun 20 2018,
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 |
Comment 1 by jam@chromium.org, Aug 16 2017