New issue
Advanced search Search tips
Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug

Blocked on:
issue 714769

Blocking:
issue 636111



Sign in to add a comment

Debugging garbled with clang-cl

Project Member Reported by scottmg@chromium.org, Apr 19 2017

Issue description

[service-worker-blah]c:\src\cr\src>type out\debug\args.gn
is_debug = true
is_component_build = true
enable_nacl = false
is_chrome_branded = true
symbol_level = 2
target_cpu = "x86"
is_win_fastlink = true
is_clang = true
win_console_app = true
win_linker_timing = true
use_goma = true

[service-worker-blah]c:\src\cr\src>type third_party\llvm-build\cr_build_revision
299960-1

Debugging in VS2017.

I don't have a repro other than build and debug a chrome binary for a while, but it results in very frustrating debugging experience.

Attached various messed up pieces of data. I'm not sure how to report these otherwise, but in each one I would expect to be able to see the values in the Watch window but instead it's garbage.
 
clang-optimized-away.png
418 KB View Download
clang-no-type-info.png
448 KB View Download
clang-bogus-values.png
454 KB View Download
Cc: brucedaw...@chromium.org
Perhaps this is related to is_win_fastlink=true? I generally didn't have that on until I needed it for goma+clang.

I'm rebuilding with msvc, fastlink, and goma to see how that turns out.
Here's msvc, fastlink, goma (working as expected). I'll stick with this config for a couple days to see if it breaks after some iterative builds, as my clang builds seemed to be sorta fine for a bit.
msvc-can-see-request.png
517 KB View Download
msvc-variable-contents.png
401 KB View Download
msvc-has-url.dll.png
443 KB View Download

Comment 3 by thakis@chromium.org, Apr 21 2017

Blocking: 636111

Comment 4 by r...@chromium.org, May 3 2017

The "No type information available for this symbol in url_lib.dll" errors will probably be easy to fix, since we can just look at the .objs to confirm.

The corrupt data or "optimized out" stuff looks like a result of our choice to only implement the "optimized" symbol records added in /d2Zi. More info about that here: https://bugs.llvm.org//show_bug.cgi?id=28458

Comment 5 by r...@chromium.org, May 4 2017

I found a pretty annoying code and debug info quality issue with inalloca. I'm not sure it's exactly your problem, but by looking at BeginNavigationRequest I've found something to improve, so that's a start. :)

Comment 6 by r...@chromium.org, May 4 2017

Owner: r...@chromium.org
Status: Assigned (was: Unconfirmed)
Here's one issue in functions with non-trivially copyable parameters:

struct NonTrivial {
  NonTrivial() : x(42) {}
  ~NonTrivial() {}
  int x;
};
void g(int) {}
void h(int) {}
void f(NonTrivial a, int b, int unused, int c) {
  if (b) {
    g(c);
  } else {
    h(a.x);
  }
}
int main() {
  NonTrivial x;
  f(x, 1, 2, 3);
}

Breaking on 'g' in windbg and printing locals gives:

0:000> dv
              a = <value unavailable>
              b = <value unavailable>
              c = <value unavailable>

This is a 32-bit only issue, though.

Comment 7 by r...@chromium.org, May 9 2017

I'm convinced that screenshots 1 & 3 are the issue identified in c#6, and that should be fixed after LLVM r302578.

I'm not sure what's up in screenshot number 2, so I'll try to repro it in VS soon.

Comment 8 by r...@chromium.org, May 10 2017

Scott, can you elaborate on how to get to screenshot #2? What flags do I need to run content_browsertests.exe with and do I need VsChromium for child process debugging? I tried this and it gives CHECK failures:
  content_browsertests.exe --gtest_filter=ServiceWorkerVersionBrowserTest.* --single-process-tests --single-process

The object file for resource_dispatcher_host_impl.cc has looks like it has good type information for new_request.
I was using content_shell, not content_browsertests, and just running it normally (i.e. not single process). Maybe running with --enable-browser-side-navigation to get to the function that's in the stack there.

I also think it might have been working at some point, and then after some iteration stopped working. I don't have a clang build handy at the moment to confirm it's an "always" repro, but I can confirm that tomorrow.
Oh, and no need for any extensions, etc. as that code is in the browser process.

Comment 11 by r...@chromium.org, May 10 2017

Thanks, I tried content_shell, although your screenshot shows content_browsertests in the Window title. *shrug*

Anyway, I stopped at the right point and new_request expands just fine for me locally in VS 2015.

Do you think this is a problem that arises while debugging over time, or do you want to call the issue fixed?
new-request-contents.png
117 KB View Download

Comment 12 by r...@chromium.org, May 10 2017

Well, the issue isn't really fixed until we roll clang, so let's get started on that.

Comment 13 by r...@chromium.org, May 10 2017

Blockedon: 714769
Hmm, ok, maybe I was lying, sorry.

Dunno, if you think things have improved, I'm happy to call it fixed for now and try switching again and see how it goes.
FYI, r303273 has been rolled as per https://codereview.chromium.org/2884383004
It's also been reverted again. It's best to wait at least 12h after a clang roll lands before doing anything that depends on it.
Status: Fixed (was: Assigned)
A clang roll with the fix landed last Friday. scottmg, can you check that things are better now?

Sign in to add a comment