WE (current stable version and nightly) often crash VS 2013 upon building project #871
Comments
|
Some more info that may or may not help. If I run VS as Administrator, then build my project, no crash. But then I build again, and I get a crash. if I debug devenv.exe during this. I get: System.IO.IOException was unhandled Endpoint.js is the compiled version of Endpoint.ts. Endpoint.ts (and some other source files) were open in the editor. So, trying again, I closed all open files and I can't seem to get VS to crash like it had been. So then I just opened a different TS file (main.ts) and I edited the file with a blank line, and when I tried to build, I get the same sort of trace. I'm going to see if I get similar problems with a new TS project. |
|
And please test it with the latest nightly build of WE andVS 2013 Update 2 RC. |
|
Sorry… I should have specified. I'm already using VS 2013 Update 2 RC and the latest nightly (from 4/6/2014) I have just tested with a new TS project and I can't duplicate the crash I was getting on my existing project. |
|
Update: Just tested with the latest Nightly version of WE 2013 and the issue persists. |
|
I am having similar issue with WE Update 2 RC (2.0.2) where VS crashes when saving a JavaScript file that is included in a bundle. I can stop VS from crashing by commenting out the file references in the bundle before editing and saving the script files. The event viewer points to a WinIOError and using procmon there is a sharing violation that occurs on the bundle output file. If minify is set to true the sharing violation usually occurs when trying to create the min file. I have noticed that the frequency that VS crashes seems to be related to the number of files in the bundle. 2-3 files takes about 5-10 edits and saves to force a crash. More than 5 files in the bundle and it will crash in 1 or 2 save attempts. Bundle output file name is app.js: Application: devenv.exe |
|
Same problem here. Also using VS 2013 Update 2 and WE RC2. |
|
I previously wasn't able to reproduce the issue with a new project if the project was created on a network share, but if I create a new project on my local drive (where my existing project that was having the issue is located), I can reproduce it. The steps I took to reproduce:
The event log has this error (appears to be exact same error previously mentioned): Immediately after that event in the Application event log, there is this Application Error, if it helps at all: |
|
Changing this code to: using(var reader = File.OpenText(TargetFilePath))
{
OnCompilationReady(new CompilerResultEventArgs(
CompilerResultFactory.GenerateResult(
sourceFileName: SourceFilePath,
targetFileName: TargetFilePath,
isSuccess: true,
result: reader.ReadToEnd(),
errors: null
)));
}might solve this issue. Can you guys try it, if you have VS-SDK installed? Fork the project, clone it via VS, open solution, make the aforementioned changes, set EditorExtensions as a startup project, start (will launch experimental instance of VS), open the culprit project and test. If it fixes the issue, please send the PR. |
|
You would also need to pass a more relaxed |
|
I've forked/cloned the project, and upon making the change you suggested and trying to modify then build my test project in the experimental VS instance, I get this IO exception: System.IO.IOException was unhandled I tried with my main project that first alerted me to the issue just to be sure and get the same thing. |
|
Can you try with: using(FileStream fileStream = File.Open(TargetFilePath, FileMode.Open, FileAccess.Read))
using(StreamReader reader = new StreamReader(fileStream))
{
...
}OR using(FileStream fileStream = new FileStream(TargetFilePath, FileMode.Open, FileAccess.Read, FileShare.Read))
using(StreamReader reader = new StreamReader(fileStream))
{
...
} |
|
I've tried both of those suggestions (even after re-forking the latest repository) and I get the same error :-( |
|
We can prevent it from crashing on async exceptions by properly terminating every async action with All of these errors should be avoidable with If that happens often, we can make an async wrapper method that catches the exception and waits a few hundred milliseconds, then tries again. |
|
That's a great idea. I was hoping if file watcher provides some event for this.. We can probably make a job queue service for read/write I/O operations and then serve all the related calls made by WE to this service. All those calls must be |
|
Here are couple of examples, we can select one and offload the read / write tasks to it:
|
|
@kgi-cwells, since I can't reproduce this crashing issue reported by many, would you please bare with me and follow these steps:
Now test if it fixes the issue. :) |
|
@am11 - I tried this, and upon my second build of my test project I get pretty much the same error, just different stacktrace with the new code: System.IO.IOException was unhandled by user code |
|
@SLaks, I have made some changes you suggested plus the retry logic when file IO exceptions are thrown, using Microsoft Enterprise library. Here is the commit am11@fa7dd65. I tested it a bit to ensure that there is no locking issue. Please review it. @kgi-cwells, thanks for reverting. Please test with this build http://1drv.ms/1nGnPaW, made for the aforementioned commit, and let us know how does it perform.. |
|
@am11 - I tested with that provided build and I get crashes with same frequency (either after building just after a build, or after editing and saving a .ts file). Although the trace is different now: Application: devenv.exe Just to be safe, I re-tried after disabling the WE extensions and I get no errors/crashes. |
|
@am11 To fix this, you need to add (instead of |
|
It seems like the issue is either:
public RetryPolicy (
int retryCount,
TimeSpan minBackoff,
TimeSpan maxBackoff,
TimeSpan deltaBackoff
)Anyone who can reproduce this issue can play with these parameters to make some progress. It isn't predictable what other process or WE thread might be capturing the file handler at the time of thrown and how persistent/permanent is their bond. Perhaps time delay is not even a solution here? |
|
@SLaks, I have changed awaited calls to DontWati in Also updated the visx http://1drv.ms/1nGnPaW. Cc: @kgi-cwells, @RaptorCZ, @blowsie, @joneff, @ShaneGarza, @tomvdk; your feedback would really help! |
|
@am11 the update no longer crashes VS. Still, the files are not compiled and the ts template is missing. |
|
This one happens when I open Sass (scss files) after updating to v.2.0.4 If a sass file has any content e.g. different from mixins VS crashes. If the file has only mixins it's fine. Happens both with From event logger and also Another interesting thing is that when I open a mixin file it automatically compiles all sass files that reference it. |
|
@joneff, thanks for reverting! :)
This is due to the Would you please share contents of your SCSS file via http://gist.github.com or http://pastebin.com? |
|
@SLaks, some unit tests are failing. One of which is Moreover, the exception suggests the VSHost is not waiting for async task: Test Name: PathNormalizationTest Test FullName: WebEssentialsTests.LessCompilationTests.PathNormalizationTest Test Source: c:\Users\Adeel\Source\Repos\WebEssentials2013\WebEssentialsTests\Tests\NodeExecutors\LessCompilationTests.cs : line 65 Test Outcome: Failed Test Duration: 0:00:09.9597406 Result Message: The test adapter 'VsIdeHostAdapter' threw an exception while running test 'PathNormalizationTest'. Failed to read from an IPC Port: The pipe has been ended. If I disable settings file ( Test Name: PathNormalizationTest Test FullName: WebEssentialsTests.LessCompilationTests.PathNormalizationTest Test Source: c:\Users\Adeel\Source\Repos\WebEssentials2013\WebEssentialsTests\Tests\NodeExecutors\LessCompilationTests.cs : line 65 Test Outcome: Failed Test Duration: 0:00:00.0591673 Result Message: Test method WebEssentialsTests.LessCompilationTests.PathNormalizationTest threw exception: System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\Adeel\Source\Repos\WebEssentials2013\TestResults\Adeel_ADEEL-HP-PC 2014-04-14 13_24_10\Out\fixtures\less'. Result StackTrace: at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileSystemEnumerableIterator`1.CommonInit() at System.IO.FileSystemEnumerableIterator`1..ctor(String path, String originalUserPath, String searchPattern, SearchOption searchOption, SearchResultHandler`1 resultHandler, Boolean checkHost) at System.IO.Directory.EnumerateFiles(String path, String searchPattern, SearchOption searchOption) at WebEssentialsTests.LessCompilationTests.d__d.MoveNext() in c:\Users\Adeel\Source\Repos\WebEssentials2013\WebEssentialsTests\Tests\NodeExecutors\LessCompilationTests.cs:line 65 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter.GetResult() Which is correct as the Do we need Momentarily, |
|
@am11 I know about chained compiles, but I thought those work on save basis, where as currently it works on view (open) basis. See the attached video -- https://dl.dropboxusercontent.com/u/6677802/chained_comile_on_view.swf On the crashing part, I am still not sure how it happens and I am trimming down a case. |
|
@joneff, this is by design. When a CSS preprocessor source file (LESS/SCSS) is opened in editor, WE compiles it in a background and generates its sourcemaps, parse them and enable some enhanced features (CSS specificity, Go To Definition, selector path in tooltip et el.). |
|
@am11 I tested on another computer with v2.0.3 and WE doesn't work like that. It waits until I save the includes ( _part.scss if we are referring to the example) and then it compiles. Also, why is it that includes are compiled on open, where as other files are compiled on save? Wouldn't other files feel neglected ;) I also have a source controlled project with ~1k sass files that all use the same includes and it's a minor nuance to cancel all 1k checkout dialogs just because I opened my mixins to check something. |
|
The dialog will only appear if target file (css or js) is opened in editor. Also, apparently Please don't hesitate in implementing these awesome features and sending PRs. (-8 |
|
@am11 - With that latest visx build, I finally do not have any crashes of VS, BUT, occaisionally I get the following in my build output window: 1>------ Build started: Project: testerror, Configuration: Debug Any CPU ------ It's still seemingly random though. Sometimes I can edit the .ts file, save, then build and that exception doesn't happen. other times, it does happen. At least devenv.exe isn't crashing now. |
|
I have multiple crash here also with the latest nightly. One is in https://github.com/madskristensen/WebEssentials2013/blob/master/EditorExtensions/CSS/QuickInfo/Selector/SelectorQuickInfo.cs#L81 => The second is in https://github.com/madskristensen/WebEssentials2013/blob/master/EditorExtensions/Shared/Margins/CssTextViewMargin.cs#L43 => _compilerResult is null |
|
@gcastre please test with this interim build http://1drv.ms/1nGnPaW. @kgi-cwells, that's some progress (with @SLaks's To make it more robust, we still might need to figure out if the file capture is really transient, then adjust RetryPolicy and the File IO strategy for this RetryPolicy (as mentioned here: #871 (comment)). |
* Uses Enterprise Library for "retry policy". * Routes all File IO read/write calls to helper. * Fixes CoffeeScript, SCSS and LESS compilation- related issues. * Fixes TypeScript crashing issues. * Fixes tests. * Other minor fixes. * Targeting madskristensen#871, madskristensen#887, madskristensen#890, madskristensen#897, madskristensen#868 & madskristensen#904.
|
@am11 I've notice that the IntellisenseParser and the ScriptIntellisenseListener share the same code listening to the change on the file. This cause the c# class to be generated in typescript (or javascript) twice. see the change here gcastre@129251e If this is indeed a refactoring mistake I'll make the PR |
|
That's a good idea. However I am unable to reproduce this issue. Here are the steps:
using System.Web.Optimization;
namespace WebApplication1.App_Start
{
public class CoffeeMinify : JsMinify
{
public CoffeeMinify() { }
public double MyProperty { get; set; }
}
}
declare module server {
interface CoffeeMinify {
MyProperty: number;
}
}Do you have different reproduction steps? We also have Would you please write a test case which is failing so we can track through it? OAN, you might find that some 9-13 unit tests are failing. Don't worry about them. VSHost times out on deep async process with following exception: Several workarounds for this IPC Port exceptions are available online. We need to find the one for our setup and fix it at some point. But rest assured, all the intellisense cases are passes. If one fail, keep trying. I closed everything before running UTs to get maximum throughput. But still when VSHost crash from test instance, the test result has some false positives. Selecting small chunks of tests and retrying passed all but 9-13. Perhaps @DerAlbertCom and @SLaks have some insights.. Finally, since you are looking into intellisense, you might like to take a stab at this feature request #495. 😄 |
|
Fixed in latest nightly |
* Uses Enterprise Library for "retry policy". * Routes all File IO read/write calls to helper. * Fixes CoffeeScript, SCSS and LESS compilation- related issues. * Fixes TypeScript crashing issues. * Fixes tests. * Other minor fixes. * Targeting madskristensen#871, madskristensen#887, madskristensen#890, madskristensen#897, madskristensen#868 & madskristensen#904.
I have an existing project that builds fine with WE disabled, but when I enable WE and then build the project, VS crashes about 75% of the time. Event log shows the following error:
Application: devenv.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.IOException
Stack:
at System.IO._Error.WinIOError(Int32, System.String)
at System.IO.FileStream.Init(System.String, System.IO.FileMode, System.IO.FileAccess, Int32, Boolean, System.IO.FileShare, Int32, System.IO.FileOptions, SECURITY_ATTRIBUTES, System.String, Boolean, Boolean, Boolean)
at System.IO.FileStream..ctor(System.String, System.IO.FileMode, System.IO.FileAccess, System.IO.FileShare, Int32, System.IO.FileOptions, System.String, Boolean, Boolean, Boolean)
at System.IO.StreamReader..ctor(System.String, System.Text.Encoding, Boolean, Int32, Boolean)
at System.IO.File.InternalReadAllText(System.String, System.Text.Encoding, Boolean)
at System.IO.File.ReadAllText(System.String)
at MadsKristensen.EditorExtensions.TypeScript.TypeScriptCompilationNotifier.RaiseReady()
at MadsKristensen.EditorExtensions.TypeScript.TypeScriptCompilationNotifier.FileTouched(System.Object, System.IO.FileSystemEventArgs)
at System.IO.FileSystemWatcher.OnChanged(System.IO.FileSystemEventArgs)
at System.IO.FileSystemWatcher.NotifyFileSystemEventArgs(Int32, System.String)
at System.IO.FileSystemWatcher.CompletionStatusChanged(UInt32, UInt32, System.Threading.NativeOverlapped)
at System.Threading.IOCompletionCallback.PerformIOCompletionCallback(UInt32, UInt32, System.Threading.NativeOverlapped)
The text was updated successfully, but these errors were encountered: