Aspnetcore: 'StartWorkTimer' must be called on the foreground thread.

Created on 18 Jun 2019  路  19Comments  路  Source: dotnet/aspnetcore

Is this a Bug or Feature request?:

Bug

Steps to reproduce

Have razor file open, possibly also be in debugging mode.

Description of the problem:

Razor language server stops unexpectedly and without any real indication of what triggers the stop.

Expected behavior:
Razor language server to not stop unexpectedly.

Actual behavior:
Razor language server stops unexpectedly.

razor file/log
https://gist.github.com/eevahr/c25c22612563740b9570a9f8871567fb

Done area-mvc bug

Most helpful comment

It's crashing for me every time I type itemscope and itemtype when implementing tags for schema.org SEO.

ya I figured out what the issue was. Sadly it's an embarrassingly obvious fix 馃槩. I'll make sure the fix gets included in the 3.1 timeline

All 19 comments

Thanks for the report @eevahr! I wonder what could be going wrong here hmmm. I'll have to take a deeper look.

I would like to second the report. Happens for me on VS Code 1.34.0, C# extension 1.20.0 ,.NET Core SDK 2.2.300. Unfortunately, I can't share stack traces because my company does not allow file uploads.

All I remember is that this exception happens and causes the Razor Language Server to be restarted a lot, crashing immediately with an RpcException every time until VS Code stops restarting it.

Same issue. Within the past month or so, VS Code on Mac has repeatedly begun crashing while editing Razor .cshml pages. The stack trace is typically StartWorkTimer must be called on the foreground thread

Issue remains in C# Extension 1.21.0.
Happened last time when creating a Razor comment (@* *@).

Issue remains in C# Extension 1.21.0.
Happened last time when creating a Razor comment (@* *@).

Yup, we haven't had the bandwidth to push out an official fix for this quite yet. Sorry! 馃槩

Sorry if my previous comment came across as a complaint.

I just meant to inform you that commits in 1.21.0 have not inadvertently fixed the issue, given that you had said you were still looking into the cause of this issue, and that other people in the thread mentioned this might be a regression _("Within the past month or so...")_

That being said, would you be able to share with us if a cause has been identified? (if/when you have time to do so, of course)

Definitely!

@NTaylorMullen If it helps, this exact JsonRpc.Server crash occurs reproducably, every time on my Macbook (VS Code with dotnet Core 2.1) right after I press the "dot" in Orchard. as shown in this example:
https://www.youtube.com/watch?v=4o9zG17cfa0&feature=youtu.be&t=1391

@nkev thank you for the exact info. That'll definitely help in reproducing on my end 馃槃

It's crashing for me every time I type itemscope and itemtype when implementing tags for schema.org SEO.

It's crashing for me every time I type itemscope and itemtype when implementing tags for schema.org SEO.

ya I figured out what the issue was. Sadly it's an embarrassingly obvious fix 馃槩. I'll make sure the fix gets included in the 3.1 timeline

Is this thread related to Razor crashing? Because mine's now crashing every time I type. I restart VS Code and as soon as I start typing it's spitting out logs with every word until finally says connection stopped.

Is this thread related to Razor crashing? Because mine's now crashing every time I type. I restart VS Code and as soon as I start typing it's spitting out logs with every word until finally says connection stopped.

Yes. Given the nature of the issue it can happen any time. If you have a lot of work running in the background it'll probably happen more frequently though

Would you be able to give a little more detail on what was causing the problem? I'm curious to hear of what was going on.

Would you be able to give a little more detail on what was causing the problem? I'm curious to hear of what was going on.

Sure. The gist is we have a timer that will start "calculating" diagnostics after a Razor document has been parsed in the background. Typically that calculation is quite quick; however, in the case that another document parse result gets ready while still calculating diagnostics we have a slight optimization to immediately re-start our timer once the previous calculation has finished. The problem lied in how we restarted the timer. At the time we were requiring that the timer be restarted on a specific thread (to ensure we don't create 2) but in the restart case we weren't actually restarting it on the appropriate thread which is why things would explode with the error. The fix involved removing the restriction to start the timer on a specific thread because we were already locking on the instantiation of the timer to ensure we didn't create more than one.

Code fix: https://github.com/aspnet/AspNetCore-Tooling/pull/1294/files#diff-f09144ac9f417245aaf102044534295cL90

I could publish to a GitHub repo and show my really bad code lol but it is very light code, very very small .Net Core PWA. Never had this problem on my project before. I also have a Surface Pro 6, i7, 16GB and definitely not enough running to cause a breakdown with each typed word. Constant breakdown also. It's like I can no longer use VS Code anymore.

It's like I can no longer use VS Code anymore.

totally understand, sorry @DanJ210! Stay tuned any we'll have this fixed for 3.1 (not too far away)

Ok no problem @NTaylorMullen I love VS Code and I appreciate all you guys/girls do to make it great while dealing with us problem preachers lol. Thank you.

Sure. The gist is we have a timer t... we didn't create more than one.

Code fix: https://github.com/aspnet/AspNetCore-Tooling/pull/1294/files#diff-f09144ac9f417245aaf102044534295cL90

This bug was preventing me from really being able to use the razor autocomplete features in vscode, so seeing it fixed is great. Thank you for the explanation as well.

Was this page helpful?
0 / 5 - 0 ratings