NuGet / Home

Repo for NuGet Client issues
Other
1.49k stars 250 forks source link

UI Hang - Deadlock initializing NuGet.SolutionRestoreManager.RestoreManagerPackage #4371

Closed rrelyea closed 7 years ago

rrelyea commented 7 years ago

Notes from Internal bug: 369371 This is a deadlock in initializing an async package

The package being initialized is NuGet.SolutionRestoreManager.RestoreManagerPackage.   From msenv.dll!CVsPackageMgr::CVsPackageInfo::SitePackage:       // THREADING: This will deadlock if the users async task needs to run code on the UI thread     // to complete and they have scheduled it using the WPF dispatcher (directly, which would be     // very hard for an async loading package, or indirectly via something like ThreadHelper.BeginInvoke).     // What they need to do is use the task library stuff or joinable task factory instead. If you are     // investigating a deadlock in your package and are reading this under the debugger then 'they' means     // 'you'.

emgarten commented 7 years ago

@alpaix any updates on this issue? This has a fairly high hit count. Not clear if all 43 hits are from NuGet however.

rrelyea commented 7 years ago

Probably not fixed. Need to investigate. 34 hits in RC2. 1 hit in RC3.

emgarten commented 7 years ago

1 hit on RC.4 it looks like this may have been improved by: NuGet/NuGet.Client@abb6b0e964e1eb3ee89bd9003db0c056fbd285e7 and looking at that hit, it doesn't look like we are involved.

emgarten commented 7 years ago

In investigating the hang dump from RC.4 I do not see NuGet.SolutionRestoreManager as loaded in the hang. I believe a different VSIX is causing these remaining hangs.

The original issue with NuGet seems to be fixed.

rrelyea commented 7 years ago

Old title: [Watson] apphangb1: APPLICATION_HANG_BusyHang_cfffffff_Microsoft.VisualStudio.Shell.15.0.dll!Microsoft.VisualStudio.Shell.VsTaskLibraryHelper+cDisplayClass24_0_1+AsVsTask_b__1_d[[System.Canon,_mscorlib]].MoveNext