New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Access Violation Exception when running JSX handler in Visual Studio debugging session #28
Comments
Are you on |
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! |
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 Do you have any debug info at all, even a single stack frame? |
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? |
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:
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. |
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. |
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 :( |
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. |
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. |
I did try |
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 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. |
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! |
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. |
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. |
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.
|
Fixing ObjectDisposedException thrown by MD5 provider being used in a non-threadsafe context.
@jlchmura Is that the cause of the Access Violation Exception? |
@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. |
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. |
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. |
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? |
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. |
I originally used MSIE because it doesn't require any additional unmanaged I think I'll split MSIE support into a separate package and make people Sent from my mobile.
|
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 |
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
instead of the existing dependencies. |
We get crashes all the time in IIS even with V8. Same stuff. |
@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. |
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. |
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 |
Please note that this is not a consistently reproducible issue AFAICT.
Occasionally, and this seems to be about on average once an hour or so during active development, when going through this process (my normal react.js dev workflow) it results in a catastrophic Access Violation Exception:
Due to the obscure nature of the exception, that it says "Unknown Handler", and that I have no call stack or target site, I can't give any further information about the exception itself. I assume it is occurring in the MSIE integration layer, but that is just a guess. I also have yet to deploy this app to any kind of production environment, so this is at least a developer environment / IIS Express issue. I can not confirm if this does or does not happen using full IIS.
While I can't do anything explicitly to reproduce this, I can say that this happens at least under this criteria:
And, if it's relevant (due to the MSIE engine), here's my system info:
If you would like me to try anything explicitly on my machine to try to reproduce this issue, let me know and I'd be happy to help. Also, I'm interested to know if anyone else has encountered this issue.
The text was updated successfully, but these errors were encountered: