New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug

Blocked on:
issue 753944

Blocking:
issue 636111



Sign in to add a comment

Dumping a Type Hangs Windbg

Project Member Reported by robliao@chromium.org, Aug 7 2017

Issue description

Canary Windows
00007ff8`2a870000 00007ff8`2d818000   chrome     (deferred)             
    Image path: C:\Users\robliao\AppData\Local\Google\Chrome SxS\Application\62.0.3178.0\chrome.dll
    Image name: chrome.dll
    Browse all global symbols  functions  data
    Timestamp:        Sat Aug  5 22:32:53 2017 (5986AA05)
    CheckSum:         02ED7E26
    ImageSize:        02FA8000
    File version:     62.0.3178.0
    Product version:  62.0.3178.0
    File flags:       0 (Mask 17)
    File OS:          4 Unknown Win32
    File type:        1.0 App
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Google Inc.
    ProductName:      Google Chrome
    InternalName:     chrome_dll
    OriginalFilename: chrome.dll
    ProductVersion:   62.0.3178.0
    FileVersion:      62.0.3178.0
    FileDescription:  Google Chrome
    LegalCopyright:   Copyright 2016 Google Inc. All rights reserved.


windbg hangs for minutes on two different machines at this point:
0:049> ?? ((chrome!base::internal::TaskSchedulerImpl*)0x0000027a`80b1e920)
class base::internal::TaskSchedulerImpl * 0x0000027a`80b1e920
   +0x000 __VFN_table : 0x00007ff8`2cef76d0 
   +0x008 name_            : 

0:056> dt  chrome!base::internal::TaskSchedulerImpl 0x0000027a`80b1e920
   +0x000 __VFN_table : 0x00007ff8`2cef76d0 
   +0x008 

windbg is hung here:
   1  Id: 7238.7230 Suspend: 1 Teb: 000000c9`d0484000 Unfrozen
 # Child-SP          RetAddr           Call Site
00 000000c9`d087bfd8 00007ff8`341a31aa dbghelp!RangeMapWrite+0x20a90
01 000000c9`d087bfe0 00007ff8`34188775 dbghelp!RangeMapWrite+0xbf05a
02 000000c9`d087c030 00007ff8`341a3838 dbghelp!RangeMapWrite+0xa4625
03 000000c9`d087c0f0 00007ff8`341a3583 dbghelp!RangeMapWrite+0xbf6e8
04 000000c9`d087c180 00007ff8`341a6f45 dbghelp!RangeMapWrite+0xbf433
05 000000c9`d087c1f0 00007ff8`341a3f23 dbghelp!RangeMapWrite+0xc2df5
06 000000c9`d087c220 00007ff8`34116eb0 dbghelp!RangeMapWrite+0xbfdd3
07 000000c9`d087c260 00007ff8`341708c4 dbghelp!RangeMapWrite+0x32d60
08 000000c9`d087c290 00007ff8`34126d6a dbghelp!RangeMapWrite+0x8c774
09 000000c9`d087c2c0 00007ff8`33c669df dbghelp!RangeMapWrite+0x42c1a
0a 000000c9`d087c300 00007ff8`33d211aa dbgeng!Debugger::DataModel::Host::HostSymbolEnumerator::GetNext+0x6f
0b 000000c9`d087c380 00007ff8`33d6b925 dbgeng!Debugger::DataModel::EE::Eval::ExpressionIdentifierBinder::InternalBind+0x20ba
0c 000000c9`d087c7c0 00007ff8`33d1dcdf dbgeng!Debugger::DataModel::Provider::NatVis::NatVisIdentifierBinder::BindName+0xcf5
0d 000000c9`d087c8b0 00007ff8`33d1cc92 dbgeng!Debugger::DataModel::EE::Eval::ResolutionVisitor::VisitIdentifier+0x2cf
0e 000000c9`d087c950 00007ff8`33d6be2c dbgeng!Debugger::DataModel::EE::Eval::ResolutionVisitor::ResolveTree+0x5d2
0f 000000c9`d087ca20 00007ff8`33d6bfc0 dbgeng!Debugger::DataModel::Provider::NatVis::NatVisParseVerifierVisitor::ResolveTree+0x50
10 000000c9`d087ca90 00007ff8`33d32f82 dbgeng!Debugger::DataModel::Provider::NatVis::NatVisParseVerifierVisitor::VisitIdentifier+0x30
11 000000c9`d087cac0 00007ff8`33d6c028 dbgeng!Debugger::DataModel::EE::Parse::ParseTreeVisitor::VisitBinaryOp+0x42
12 000000c9`d087caf0 00007ff8`33d6bf06 dbgeng!Debugger::DataModel::Provider::NatVis::NatVisParseVerifierVisitor::VisitBinaryOp+0x48
13 000000c9`d087cb60 00007ff8`33d6dac8 dbgeng!Debugger::DataModel::Provider::NatVis::NatVisParseVerifierVisitor::EvaluateExpression+0x72
14 000000c9`d087cb90 00007ff8`33d77220 dbgeng!Debugger::DataModel::Provider::NatVis::CanParseExpression+0x478
15 000000c9`d087cd60 00007ff8`33d65d05 dbgeng!Debugger::DataModel::Provider::NatVis::NatVisParseChecker::CheckExpression+0x70
16 000000c9`d087cdf0 00007ff8`33d65a2e dbgeng!Debugger::DataModel::Provider::NatVis::NatVisConcept::_ParseCheckDisplayStringList+0x165
17 000000c9`d087cec0 00007ff8`33d55eb5 dbgeng!Debugger::DataModel::Provider::NatVis::NatVisConcept::CanParse+0x162
18 000000c9`d087cf90 00007ff8`339d199f dbgeng!Debugger::DataModel::Provider::NatVis::NatVisDataModelSelector::GetValue+0x185
19 000000c9`d087d030 00007ff8`339d9e11 dbgmodel!KeyStore::InternalGetDataModelForContext+0xa3
1a 000000c9`d087d0b0 00007ff8`339d99c7 dbgmodel!ModelObject::InternalNotifyInitializedInstance+0x105
1b 000000c9`d087d140 00007ff8`339e39fa dbgmodel!ModelObject::RuntimeClassInitialize+0x147
1c 000000c9`d087d190 00007ff8`339dd385 dbgmodel!Microsoft::WRL::Details::MakeAndInitialize<ModelObject,IModelObject,DataModelManager * __ptr64 const,IDebugHostContext * __ptr64 & __ptr64,Location & __ptr64,IDebugHostType * __ptr64 & __ptr64,ModelObject * __ptr64,IDebugHostTypeSignature * __ptr64,IDebugHostSymbolEnumerator * __ptr64>+0xe2
1d 000000c9`d087d210 00007ff8`33c1e3d0 dbgmodel!DataModelManager::CreateTypedObject+0x105
1e 000000c9`d087d2c0 00007ff8`33c24731 dbgeng!GetDmlElement+0x100
1f 000000c9`d087d380 00007ff8`33c28412 dbgeng!DbgTypes::ProcessDataMemberType+0xd49
20 000000c9`d087d520 00007ff8`33c25c60 dbgeng!DbgTypes::ProcessType+0x5ba
21 000000c9`d087d6b0 00007ff8`33c281ea dbgeng!DbgTypes::ProcessUDType+0xbc4
22 000000c9`d087d890 00007ff8`33c215ec dbgeng!DbgTypes::ProcessType+0x392
23 000000c9`d087da20 00007ff8`33c2c149 dbgeng!DbgDerivedType::DumpType+0x30
24 000000c9`d087da50 00007ff8`33c48b64 dbgeng!OutputTypeByIndex+0x151
25 000000c9`d087ddb0 00007ff8`33c48a72 dbgeng!TypedData::OutputFullValue+0x354
26 000000c9`d087deb0 00007ff8`33bb6015 dbgeng!TypedData::OutputFullValue+0x262
27 000000c9`d087dfb0 00007ff8`33bb638f dbgeng!EvalCurrentAndOutput+0xe5
28 000000c9`d087e080 00007ff8`33bb8aca dbgeng!EvaluateTypedExpr+0x227
29 000000c9`d087e160 00007ff8`33bb9be9 dbgeng!ProcessCommands+0xd4a
2a 000000c9`d087e2b0 00007ff8`33af0cb3 dbgeng!ProcessCommandsAndCatch+0xa5
2b 000000c9`d087e320 00007ff8`33af0f93 dbgeng!Execute+0x2bb
2c 000000c9`d087e810 00007ff7`bb578bb9 dbgeng!DebugClient::ExecuteWide+0x83
2d 000000c9`d087e870 00007ff7`bb579040 windbg!ProcessCommand+0x2b1
2e 000000c9`d087ec90 00007ff7`bb57b4ec windbg!ProcessEngineCommands+0x16c
2f 000000c9`d087fce0 00007ff8`60588364 windbg!EngineLoop+0x5ec
30 000000c9`d087fd70 00007ff8`615170d1 KERNEL32!BaseThreadInitThunk+0x14
31 000000c9`d087fda0 00000000`00000000 ntdll!RtlUserThreadStart+0x21

We spend a long time in
dbgeng!Debugger::DataModel::Host::HostSymbolEnumerator::GetNext
it seems.
 
Blocking: 636111
Cc: r...@chromium.org
Is this new? If so, it might be called by yesterday's clang roll (and if so, we should revert that).
I do not know if it's new.
Then it probably isn't new. In case it's important, windbg version?
windbg and dbgeng
10.0.15063.468 

dbghelp
10.0.16173.1001

I don't know what gab's versions are as he also repro'ed this.

And both of you tried this for the first time today and didn't try this last week, yes?
Correct. We were investigating a new issue.

Comment 7 by r...@chromium.org, Aug 7 2017

Does this repro with a static release build of chrome without any official bits? I'm wondering if this problem is unique to official, branded builds.

Does this repro if you just do `dt chrome!base::internal::TaskSchedulerImpl`, with no address?

Comment 8 by r...@chromium.org, Aug 7 2017

I built an x64, static, release version of Chrome, and got a normal dump from dt:

0:000> dt chrome_7ffdd8dc0000!base::internal::TaskSchedulerImpl
dtx is unsupported for this scenario.  It only recognizes dtx [<type>] [<address>] with -a, -h, and -r.  Reverting to dt.
*** WARNING: Unable to verify checksum for C:\src\chromium\src\out\clang\chrome.dll
   +0x000 __VFN_table : Ptr64 
   +0x008 name_            : std::basic_string<char, std::char_traits<char>, std::allocator<char> >
   +0x028 service_thread_  : base::Thread
   +0x0a8 task_tracker_    : std::unique_ptr<base::internal::TaskTracker, std::default_delete<base::internal::TaskTracker> >
   +0x0b0 delayed_task_manager_ : base::internal::DelayedTaskManager
   +0x0e8 single_thread_task_runner_manager_ : base::internal::SchedulerSingleThreadTaskRunnerManager
...

I appear to have a different version of windbg: Microsoft (R) Windows Debugger Version 10.0.14321.1024 AMD64

I guess I install a more recent win10 sdk to get the newer one with the bugs?

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

I upgraded my Win10 SDK and I can repro the issue now. The address appears to be necessary.
Does it repro with VC++? It sounds like it doesn't so we have a bug that requires clang-cl and the latest windbg. Excellent.

If Microsoft support is needed I think that windbgfb@microsoft.com would be a good start (from https://developer.microsoft.com/en-us/windows/hardware/download-symbols). They have been responsive in the past.

Comment 11 by r...@chromium.org, Aug 8 2017

Hm, I left my workstation an hour ago and came back and it finished printing, and after that, more commands are fast. So, windbg might actually be making progress while it does something very slow.
Yep. That was my conclusion. windbg caches the computation and subsequent requests are fast. 

Whatever dbgeng!Debugger::DataModel::Host::HostSymbolEnumerator::GetNext is doing is suspiciously slow.

Generally, structure dump hangs are not common.

Comment 13 by r...@chromium.org, Aug 8 2017

Owner: r...@chromium.org
Status: Assigned (was: Untriaged)
My hope is that this is related to  issue 749805 , which is about visualizing std::string.

I need to do a clean build of Chrome to confirm, though, and then we can dupe the issues.
Blockedon: 753944
 Issue 749805  is now fixed, so we're hoping (but haven't yet checked) that this might be better now. If anyone of the people who saw this could verify if this still happens, that'd be cool. (Else we'll get around to it some time this week.)
Status: Fixed (was: Assigned)
Marking fixed as it does not hang in my development build. Thanks!
Was that check with a build before the clang revert? (Landed Friday night)
IIRC it was before the clang revert.

Sign in to add a comment