Bug 46874 - Visual Studio 2015 frequently freezes during build
Summary: Visual Studio 2015 frequently freezes during build
Status: RESOLVED DUPLICATE of bug 45278
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: General ()
Version: 4.2.0 (C8)
Hardware: PC Windows
: High normal
Target Milestone: 4.3.0 (C9)
Assignee: Bugzilla
Depends on:
Blocks: 45278
  Show dependency tree
Reported: 2016-11-12 18:10 UTC by Steve Miller
Modified: 2017-01-17 19:21 UTC (History)
10 users (show)

Is this bug a regression?: ---
Last known good build:

Logs and About Visual Studio (8.33 KB, application/zip)
2016-11-12 18:10 UTC, Steve Miller

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Steve Miller 2016-11-12 18:10:26 UTC
Created attachment 18443 [details]
Logs and About Visual Studio

Visual Studio will very frequently freeze hard when building a Xamarin Android project and the only method to recovering is force closing Visual Studio.
Comment 1 Danar jabbar 2016-11-13 17:37:02 UTC
I have exactly the same problem but what I tried is
Clean the entire solution before building the project it appears to be stable and i will update the xamarin for visual studio
Comment 3 Alan McGovern 2016-11-14 16:49:45 UTC
We need the backtrace from all the threads to diagnose this, and to fix it. It could just be another occurrence of bug #46707. Ben, can you repro it and get the traces, or is there some documentation/instructions we can pass to the reporters so they can gather it?
Comment 4 Alan McGovern 2016-11-15 11:22:20 UTC
Until we get backtraces showing it's actually an android designer issue i'll leave it assigned against the Android component. There are known deadlocks in that code whereas we do not have known deadlocks in the android designer code.
Comment 5 Adrian Alonso 2016-12-22 18:15:25 UTC
Steve, are you still experimenting this issue? Thanks, Adrian
Comment 7 Alan McGovern 2017-01-03 14:00:40 UTC
That error would not cause a hang or deadlock.

The known hangs/deadlocks are caused by the usage of AsyncManager when it does a blocking wait on async operations. I still think we need to remove all usages of that as, according to everything I've read so far, it still causes deadlocks even when used correctly.

Unfortunately there's nothing in the logs to indicate the issue was caused by AsyncManager, so until we have a confirmed cause we're just guessing.
Comment 8 Daniel Cazzulino 2017-01-03 16:15:18 UTC
There are no known deadlocks that are on our plate as far as I know. The VS team has requested full heap dumps if that is the case per your diagnosis Alan.

So, unless you can prove it's actually a VS deadlock, the stacktrace clearly shows this is a designer issue and we'll leave it in the Android Designer component.
Comment 9 Daniel Cazzulino 2017-01-03 16:19:22 UTC
Rather than logs, we need memory dumps.

@Steve @Danar if/when this happens again, could you please take such dumps to take a look? 

@Alan, the Android designer triggers another build right after the VS build completes, and that was one of the culprits in the past, which why I'm leaving it in the designer component.

Comment 10 Alan McGovern 2017-01-06 11:24:33 UTC
I uploaded the memory dumps and the issue was confirmed to be not related to the designer itself (so far). The problem is believed to be the CompleteOnCurrentThread invocation:

> Microsoft.VisualStudio.Threading.dll!Microsoft.VisualStudio.Threading.JoinableTask.CompleteOnCurrentThread() Line 839
> Merq.Async.Core.dll!Merq.AsyncManager.Run(System.Func<System.Threading.Tasks.Task> asyncMethod)
> Xamarin.VisualStudio.Android.dll!Xamarin.VisualStudio.Android.MonoAndroidDesignerPane.DisposeSession()

Reassigning this to General for now as there is still nothing actionable from our side. If there are issues with the designer they'd probably be best filed as a new bug with the relevant stacktraces/dumps attached so we can deal with them. We can use this bug to deal with the AsyncManager usage issues.
Comment 11 Alan McGovern 2017-01-06 14:56:41 UTC
The same issue is causing the deadlock in bug #45278
Comment 13 Alan McGovern 2017-01-17 18:31:53 UTC
That commit you indicated was actually the fix for this bug: https://bugzilla.xamarin.com/show_bug.cgi?id=45278.

The deadlock this bug is dealing with was mitigated by changing `AsyncManager.Run` to `AsyncManager.RunAsync` as part of this commit, https://github.com/xamarin/XamarinVS/commit/f18ef199b768479ba936908ba82d24b9ade032b1, however the usage of `AsyncManager.RunAsync` is incorrect and can lead to deadlocks.

I'm waiting for Android Arnott to review a doc before I push it to the repository, but I want to leave this bug open until we can review the remaining usages of AsyncManager.Run/RunAsync. This one will probably need to be removed.
Comment 14 Alan McGovern 2017-01-17 19:19:49 UTC
Let's assume this one is just a direct duplicate of bug #45278 then, which was an incorrect usage of AsyncManager.Run. 

I filed bug #51580 to deal with the other AsyncManager.Run issue noted in this comment: https://bugzilla.xamarin.com/show_bug.cgi?id=46874#c10

*** This bug has been marked as a duplicate of bug 45278 ***