New issue
Advanced search Search tips

Issue 624466 link

Starred by 1 user
Status: Verified
Owner:
r...@chromium.org
Closed: Jul 2016
Cc:
thakis@chromium.org
r...@chromium.org
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug



Sign in to add a comment

Missing classes and namespaces in stack trace symbols on CrWinAsan tester

Project Member Reported by h...@chromium.org, Jun 29 2016 
These tests have been failing for a while:
- unit_tests SafeBrowsingEnvironmentDataCollectionWinTest.VerifyLoadedModules
- views_unittests WidgetTest.WindowMouseModalityTest

More recently (last week or so), these started failing too:
- chrome_elf_unittests ELFImportsTest.ChromeElfSanityCheck
- content_browsertests ContentBrowserTest.BrowserCrashCallStack

In the last one, the file paths in the backtrace look weird:

	StackTrace [0x03070E24+20] (C:uild\slave\CrWinAsanuild\srcase\debug\stack_trace_win.cc:214)
	~LogMessage [0x02ED2D8C+300] (C:uild\slave\CrWinAsanuild\srcase\logging.cc:533)
	RunTestOnMainThread [0x01815B0B+155]
	RunTestOnMainThreadLoop [0x023F26D6+518] (C:uild\slave\CrWinAsanuild\src\content\public	est\content_browser_test.cc:136)

Maybe related to codeview changes?

I was looking at https://build.chromium.org/p/chromium.fyi/builders/CrWinAsan%20tester/builds/1073

The new failures show up when going from Clang r272924 to r273077.

Comment 1 by r...@chromium.org, Jun 29 2016

Owner: r...@chromium.org
Summary: Missing classes and namespaces in stack trace symbols on CrWinAsan tester (was: Tests failing on CrWinAsan tester)
I'm going to assume that the missing '\b' and '\t' bits in the path are a Chrome Python string escaping bug.

The missing name qualifiers are definitely our bug, I'll take a look. It should have worked.

Comment 2 by r...@chromium.org, Jun 29 2016 

LLVM r273358 and Clang r273008 were supposed to land together, but somehow they got separated in time by a weekend.

Comment 3 by r...@chromium.org, Jun 30 2016 

I get a good stack trace in windbg:

namespace foo {
struct Bar {
  static void baz();
};
void Bar::baz() { __debugbreak(); }
}
int main() {
  foo::Bar::baz();
}

0:000> k
 # Child-SP          RetAddr           Call Site
00 00000000`0017fed8 00000001`3f886569 t!foo::Bar::baz [D:\src\llvm\build\t.cpp @ 5]
01 00000000`0017fee0 00000001`3f886b1c t!main+0x9 [D:\src\llvm\build\t.cpp @ 9]
...

So, there must be something weird in our gyp. This might also be -gline-tables-only, do we pass that to WinASan?

Comment 5 by r...@chromium.org, Jun 30 2016 

Right, this is https://cs.chromium.org/chromium/src/build/common.gypi?q=gline-tables-only&sq=package:chromium&dr=C&l=5882

Here's what I think we should do: if -gline-tables-only is set and -gcodeview is set, compute the full display name in the frontend, so that we don't need to mess around emitting partial namespace / scope information. This might make sense for DWARF as well, but it might increase debug info size too much.

Comment 6 by r...@chromium.org, Jun 30 2016 

Clang r274246 should fix this.

Comment 7 by r...@chromium.org, Jul 7 2016

Status: Verified (was: Untriaged)
The bot isn't green but those tests are fixed.
►

Sign in to add a comment