Access Violation Exception when running JSX handler in Visual Studio debugging session

[reactjs]

Access Violation Exception when running JSX handler in Visual Studio debugging session

[paulirwin]

Original issue creator here. Wow, I can't believe it's been over 2 years since I originally filed this! Unfortunately I can't help validate with the latest changes as we no longer use this library, we now use either Webpack/Babel or the TypeScript compiler to transform our JSX. But I can say that in the last weeks that we were using this library we did still encounter this issue from time to time with V8 as our only engine in our web.config file.

[Daniel15]

Are you on React.Core 1.0 or 1.0.1? If only on 1.0, can you please try upgrading to 1.0.1 and see if the same issue occurs? NuGet seems to like only installing 1.0 even though 1.0.1 is available.

[paulirwin]

Ah ha, very strange. It did install 1.0.0 along with older versions of the dependencies even though I only installed it a few days ago, well after 1.0.1 came out, like you said. I will upgrade React.Core to 1.0.1, as well as the latest versions of JavaScriptEngineSwitcher.Jint, JavaScriptEngineSwitcher.Msie, and MsieJavaScriptEngine, and I'll post back here and let you know if it occurs again, or if it seems to be resolved after enough time testing it, I'll post that as well. Thanks for responding so quickly!

[Daniel15]

I just modified the NuGet package to hide 1.0, hopefully that means NuGet will install 1.0.1 (but I don't have access to a Windows machine at the moment so can't test it).

Let me know if upgrading JavaScriptEngineSwitcher.Msie or MsieJavaScriptEngine fixes it, in which case I'll bump the version number requirement. I have a feeling it's in the MSIE engine somewhere. I've been meaning to try V8 on Windows but I had a lot of issues getting the version required by VroomJS to compile on Windows (works fine on Linux though, I use it in production on a pretty simple page with no issues).

Do you have any debug info at all, even a single stack frame?

[paulirwin]

I just encountered the AccessViolationException again on the latest versions of all the NuGet packages. No debug info, no call stack, nothing. I agree that it is most likely in the IE engine. I guess I could try Jint and see if that helps?

[paulirwin]

I still haven't switched over to Jint yet so this is still MSIE, and I just got it again. Here's the full message:

An unhandled exception of type 'System.AccessViolationException' occurred in Unknown Module.

Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

And that's all it gives, no ability to see any other details of the exception in VS. During this, VS shows a "Code not running" tab and there's nothing in the call stack window. If I hit Continue (F5), the process shuts down and VS stops debugging.

I'm going to try removing MSIE in the web.config and use Jint and see if it happens again -- I'm guessing it won't since Jint is managed code.

[paulirwin]

I should also note that this was with a completely different application/solution than when I was getting it before, with completely different, unrelated JSX files, so it doesn't seem to be anything related to my project.

[Daniel15]

I'm having trouble replicating this on my system (Windows 8.1 64-bit, IE 11.0.9600.16521 running in VMWare Fusion). Are you on 64-bit or 32-bit? Can you replicate this issue if you build from source (instructions here) and run the included "React.Samples.Mvc4"?

Switching to Jint in the web.config won't actually work as I'm not using the JS switcher config. ReactJS.NET has its own config. Unfortunately Jint doesn't support JSX compilation at all since the stack gets too large for it to handle :(

[paulirwin]

64-bit, IE 11 on 8.1. I'll try building from source and running the samples, but I'll have to modify the samples to really test it out, as it almost never occurs on the first hit in the app, it's usually after modifying the JSX files multiple times while debugging.

Looking at the "has its own config" link to the source above, I see that you're using ChakraActiveScript. Have you tried it with ChakraJsRt mode? Just curious to know if there's a difference.

[paulirwin]

FYI - My colleague has now also received this exception on his machine, which is also 8.1 with IE 11. So this is not an isolated issue to my machine.

[Daniel15]

I did try ChakraJsRt initially but it failed since it couldn't handle the large Esprima stacks (JSXTransformer uses Esprima for parsing) so I had to stop using it. Could you please send through a small project that replicates the issue? I'm about to go on vacation but I can take a look once I'm back. Thanks!

[jlchmura]

I have the same issue happening, though my debugger is not attached at the time, but I am building in Debug mode.

VS2013 using iisexpress
64-bit Win7
Chrome

I'll make some changes to a JSX inside VS and save. When reloading the page in Chrome, IISExpress crashes with an access violation exception. It doesn't happen every time. Some times I can go 10 or more saves without crash, while other times I'll get two in a row.

[paulirwin]

Thanks @jlchmura, glad it's not just us! Also, an update, I have confirmed that our entire dev team gets this exception regularly. Hopefully someone can figure out what's happening!

[Daniel15]

It's interesting that I haven't been able to repro this :(

I'm using a virtual machine though (in VMWare Fusion). Maybe I should try it on a 'real' machine and see if I get the same error.

[jlchmura]

Another interesting bit of information:

I created a Debug build of the React.NET libraries (just pulled the source this morning) and switched my project to use those. IIS crashes have stopped. Did a Release build and they are back.

[jlchmura]

Update on this.. my previous pull request prevented the crash, but did not solve the cause. @Daniel15 - DisposeAll was being called and the environment was properly being disposed even without my change. However, I was finally able to catch the exception (below) which was being thrown in FileCacheHash. MD5.ComputeHash is not thread-safe but FileCacheHash was being registered as a singleton.

This also solves the seemingly random http 500's being thrown by the jsx handler.

I'll submit another pull request with the fix.

System.ObjectDisposedException was unhandled by user code
  HResult=-2146232798
  Message=Safe handle has been closed
  Source=mscorlib
  ObjectName=""
  StackTrace:
       at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean& success)
       at System.StubHelpers.StubHelpers.SafeHandleAddRef(SafeHandle pHandle, Boolean& success)
       at System.Security.Cryptography.Utils.HashData(SafeHashHandle hHash, Byte[] data, Int32 cbData, Int32 ibStart, Int32 cbSize)
       at System.Security.Cryptography.MD5CryptoServiceProvider.HashCore(Byte[] rgb, Int32 ibStart, Int32 cbSize)
       at System.Security.Cryptography.HashAlgorithm.ComputeHash(Byte[] buffer)
       at React.FileCacheHash.CalculateHash(String input) in c:\Users\jchmura\Documents\GitHub\ChmuraEcon\React.NET\src\React\FileCacheHash.cs:line 39
       at React.JsxTransformer.<>c__DisplayClass1.<TransformJsxFile>b__0() in c:\Users\jchmura\Documents\GitHub\ChmuraEcon\React.NET\src\React\JsxTransformer.cs:line 87
       at React.Web.AspNetCache.GetOrInsert[T](String key, TimeSpan slidingExpiration, Func`1 getData, IEnumerable`1 cacheDependencyFiles, IEnumerable`1 cacheDependencyKeys) in c:\Users\jchmura\Documents\GitHub\ChmuraEcon\React.NET\src\React.Web\AspNetCache.cs:line 71
       at React.JsxTransformer.TransformJsxFile(String filename, Nullable`1 useHarmony) in c:\Users\jchmura\Documents\GitHub\ChmuraEcon\React.NET\src\React\JsxTransformer.cs:line 79
       at React.Web.JsxHandler.Execute() in c:\Users\jchmura\Documents\GitHub\ChmuraEcon\React.NET\src\React.Web\JsxHandler.cs:line 51
       at React.Web.JsxHandlerFactory.ProcessRequest(HttpContext context) in c:\Users\jchmura\Documents\GitHub\ChmuraEcon\React.NET\src\React.Web\JsxHandlerFactory.cs:line 26
       at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
       at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
  InnerException: 

[paulirwin]

@jlchmura Is that the cause of the Access Violation Exception?

[jlchmura]

@paulirwin Yes, I believe so. Our dev machines only have a few hours of runtime with my latest build, but so far nobody has run in to the access violation. Typically we would have hit it several times already. I'd be curious to hear if it solves the issue in your environment too.

[Daniel15]

Thanks for your help @jlchmura!

@paulirwin - I've just merged @jlchmura's change so it should be available on the dev package repository once the build server picks it up. You can try out that package and let me know if you still experience the issue or if it fixes it for you.

[Daniel15]

I'm going to close this as I believe @jlchmura's fix should fix the issue. This fix is available in version 1.1.0 and I've credited @jlchmura in the changelog. Thanks!

[paulirwin]

FYI - it seems @jlchmura's fix was at least partially unrelated to this issue, as my team of 4 developers each still get this exception daily when using the MSIE engine. We switched to the V8 engine and so far we haven't gotten the exception -- I'll update here if we do, but so far so good. There definitely still seems to be a problem with the MSIE engine.

[Daniel15]

Thanks @paulirwin - I'll try to investigate the MSIE issues further, but at least you can use V8 to work around the issue :)

Are you still seeing this issue on ReactJS.NET 1.3?

[paulirwin]

No, our team has not seen the exception in the last couple weeks since switching the Web.config to use the V8 engine, and we are on ReactJS.NET 1.3.0.

To be honest, should this project consider adopting V8 as the preferred engine? It seems to work rather well, there is clear industry support for V8, and I like that ClearScript V8 packages the V8 DLLs along with your project instead of depending on MSIE on the web server. I would encourage everyone using this project to try out the V8 engine, and if after a while there aren't any issues, use that as preferred with MSIE as a fallback.

[Daniel15]

I originally used MSIE because it doesn't require any additional unmanaged
DLL files.

I think I'll split MSIE support into a separate package and make people
explicitly choose which engine they want to use (ie. Don't prefer any
particular engine by default).

Sent from my mobile.
On Dec 20, 2014 2:10 AM, "Paul Irwin" [email protected] wrote:

No, our team has not seen the exception in the last couple weeks since
switching the Web.config to use the V8 engine, and we are on ReactJS.NET
1.3.0.

To be honest, should this project consider adopting V8 as the preferred
engine? It seems to work rather well, there is clear industry support for
V8, and I like that ClearScript V8 packages the V8 DLLs along with your
project instead of depending on MSIE on the web server. I would
encourage everyone using this project to try out the V8 engine, and if
after a while there aren't any issues, use that as preferred with MSIE as a
fallback.

Reply to this email directly or view it on GitHub
#28 (comment).

[Shreeyam]

Any update on this? I get a System.AccessViolationError consistently when running my application in IIS 10, but not when debugging using IIS Express.

Edit: This is using MsieJavaScriptEngine

[beruic]

I get this consistently in VisualStudio 2015 using both IIS Express and running the program + running it from console.

I use the sample project from https://github.com/reactjs/React.NET/tree/master/src/React.Sample.Mvc6. Only change I made is in project.json where I put

"React.Core": "2.4.0",
"React.AspNet": "2.4.0"

instead of the existing dependencies.

[mwethington]

We get crashes all the time in IIS even with V8. Same stuff.

[Daniel15]

@mwethington - Could you please provide a stack trace? So far I've only seen this error with the MSIE JS engine in the stack trace.

[rickywang1981]

Hi Daniel: we also encounter AccessViolationException with V8 from time to time. The error cannot be catched by ASP.NET. Could you look into this urgent issue? This is error log while ASP.NET crashes:

Version=1
EventType=CLR20r3
EventTime=131185943235051992
ReportType=2
Consent=1
ReportIdentifier=d7a3d85c-7cde-11e6-80d8-005056853a8a
IntegratorReportIdentifier=d7a3d85b-7cde-11e6-80d8-005056853a8a
WOW64=1
NsAppName=w3wp.exe
Response.type=4
Sig[0].Name=Problem Signature 01
Sig[0].Value=w3wp.exe
Sig[1].Name=Problem Signature 02
Sig[1].Value=8.5.9600.16384
Sig[2].Name=Problem Signature 03
Sig[2].Value=52157ba0
Sig[3].Name=Problem Signature 04
Sig[3].Value=ClearScriptV8-32
Sig[4].Name=Problem Signature 05
Sig[4].Value=5.4.5.0
Sig[5].Name=Problem Signature 06
Sig[5].Value=56e184c1
Sig[6].Name=Problem Signature 07
Sig[6].Value=f7
Sig[7].Name=Problem Signature 08
Sig[7].Value=4f
Sig[8].Name=Problem Signature 09
Sig[8].Value=System.AccessViolationException
DynamicSig[1].Name=OS Version
DynamicSig[1].Value=6.3.9600.2.0.0.272.7
DynamicSig[2].Name=Locale ID
DynamicSig[2].Value=1033
DynamicSig[22].Name=Additional Information 1
DynamicSig[22].Value=f4b8
DynamicSig[23].Name=Additional Information 2
DynamicSig[23].Value=f4b83f39e04b97afc15f0c96e3a7c9c3
DynamicSig[24].Name=Additional Information 3
DynamicSig[24].Value=00a3
DynamicSig[25].Name=Additional Information 4
DynamicSig[25].Value=00a37bc75e5534558a731b6ec5129823
UI[2]=C:\Windows\SysWOW64\inetsrv\w3wp.exe
UI[5]=Check online for a solution (recommended)
UI[6]=Check for a solution later (recommended)
UI[7]=Close
UI[8]=IIS Worker Process stopped working and was closed
UI[9]=A problem caused the application to stop working correctly. Windows will notify you if a solution is available.
UI[10]=&Close
LoadedModule[0]=C:\Windows\SysWOW64\inetsrv\w3wp.exe
...
...
LoadedModule[172]=root\bin\ClearScript.V8\ClearScriptV8-32.dll
LoadedModule[173]=root\bin\ClearScript.V8\v8-ia32.dll
LoadedModule[174]=C:\Windows\SYSTEM32\MSVCP120.dll
LoadedModule[175]=C:\Windows\SYSTEM32\MSVCR120.dll
LoadedModule[176]=C:\Windows\Microsoft.NET\Framework\v4.0.30319\clrcompression.dll