Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
Grid Node - AccessViolationException - Protected Memory Issue
Options
Previous Topic Next Topic
MatthewSteeples
#1 Posted : Monday, November 19, 2018 6:59:48 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 10/28/2014(UTC)
Posts: 130
Location: United Kingdom

Thanks: 7 times
Was thanked: 18 time(s) in 16 post(s)
Quote:
System.TypeInitializationException: The type initializer for 'MVC' threw an exception. ---> System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at nCrunch.TestRuntime.SharedMemoryExecutionDataRecorder.MarkCoverageOfClass(Int32 componentMappingId, Int32 classIndex)
at LedgerscopeWeb.Controllers.T4MVC_DashboardController..ctor() in D:\Source\Repos\Core\LedgerscopeWeb\LedgerscopeWeb\DashboardController.generated.cs:line 0
at MVC..cctor() in D:\Source\Repos\Core\LedgerscopeWeb\LedgerscopeWeb\T4MVC.cs:line 43
--- End of inner exception stack trace ---
at LedgerscopeWeb.Controllers.ManagerController.<Add>d__7.MoveNext() in D:\Source\Repos\Core\LedgerscopeWeb\LedgerscopeWeb\Controllers\ManagerController.cs:line 104
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
at LedgerscopeWeb.Controllers.ManagerController.Add(ManagerUpdateRequest updateRequest)
at LedgerscopeWeb.UnitTests.Controllers.ManagerControllerTests.AddPostbackTests.<Postback_To_Add_And_Validation_Exception_Occurs_From_Service_Should_Return_To_Index_With_Model_With_Cmb_Masterpage>d__9.MoveNext() in D:\Source\Repos\Core\LedgerscopeWeb\LedgerscopeWeb.Tests\Controllers\ManagerControllerTests\AddPostbackTests.cs:line 86
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
at LedgerscopeWeb.UnitTests.Controllers.ManagerControllerTests.AddPostbackTests.Postback_To_Add_And_Validation_Exception_Occurs_From_Service_Should_Return_To_Index_With_Model_With_Cmb_Masterpage()


We're getting the above error on just one of our grid nodes. They are both configured the same apart from this one (I think) used to have full Visual Studio installed and now just has the Build Tools installed. The test in question has an async Task signature (running with MSTest) and the second line of the stacktrace (which references line 0) is an auto-generated class by T4MVC.

Windows 10 1803, .NET 4.7.2, Visual Studio 15.9.1, NCrunch 3.22.0.1

Not sure what else you want information-wise, but happy to provide anything that will help
Back to top
Remco
#2 Posted : Monday, November 19, 2018 8:04:32 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,976

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
Hi, thanks for sharing this issue.

It's interesting that this code is reporting an exception on line 0. I can see how that would lead to problems with coverage tracking.

Do you know how this is happening? Are there compiler declarations in place in your generated code to redirect the line references in the PDB?

It may be necessary to disable NCrunch's code coverage tracking for this particular file or project. I'd say you have the following options:
1. Find a way to generate the code without remapping of line numbers to non-existent lines
2. Disable code coverage tracking for the generated code by using code coverage suppression comments
3. Disable code coverage tracking for the entire project. Isolating the generated code in its own project is recommended if possible.
Back to top
MatthewSteeples
#3 Posted : Monday, November 19, 2018 8:56:49 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 10/28/2014(UTC)
Posts: 130
Location: United Kingdom

Thanks: 7 times
Was thanked: 18 time(s) in 16 post(s)
Actually, now you mention it there's one more difference. This server is running StackExchange.Precompilation to precompile our views. The summary of that project is that it turns the cshtml files into cs files at compile time and puts them in the Assembly. I bet it's hitting code in there that doesn't have line numbers specified.

An acceptable workaround for us is to declare the T4MVC.cs file as exempt from coverage. Is there an easy way to do that not using comments? Reason I'm asking is that the .cs file is autogenerated from a .tt file, so if we make the change manually it'll get overwritten next time the auto-generation is run (and if we modify the .tt file that will get overwritten next time there's a new version of T4MVC).
Back to top
 |  Edit by user
Remco
#4 Posted : Tuesday, November 20, 2018 1:17:57 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,976

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
MatthewSteeples;12831 wrote:

An acceptable workaround for us is to declare the T4MVC.cs file as exempt from coverage. Is there an easy way to do that not using comments? Reason I'm asking is that the .cs file is autogenerated from a .tt file, so if we make the change manually it'll get overwritten next time the auto-generation is run (and if we modify the .tt file that will get overwritten next time there's a new version of T4MVC).


Sadly, right now there isn't :(

The best alternative I could offer would be to turn off the instrumentation for the entire project (using the 'Instrument output assembly' setting). The unfortunate issue with doing this is that you'll lose code coverage for everything else in the project. Moving the generated code into its own project would solve this, though I expect that might not be easy to do.

What if you implemented your own build event to modify the generated T4MVC.cs file to add a line of text to the top of the file? If you can find a way to add '//ncrunch: no coverage start', the problem will be gone.
Back to top
MatthewSteeples
#5 Posted : Thursday, August 22, 2019 2:58:46 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 10/28/2014(UTC)
Posts: 130
Location: United Kingdom

Thanks: 7 times
Was thanked: 18 time(s) in 16 post(s)
That seemed to work for us for a while, but we're getting an error where we wouldn't expect now (and it doesn't happen all of the time, only intermittently - a restart solves it for a while)

Code:
NCrunch: This test was executed on server 'THREEOAKS'

System.TypeInitializationException: The type initializer for 'MVC' threw an exception. ---> System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at nCrunch.TestRuntime.SharedMemoryExecutionDataRecorder.MarkCoverageOfClass(Int32 componentMappingId, Int32 classIndex)
   at LedgerscopeWeb.Areas.Admin.Controllers.T4MVC_BackupSnapshotsController..ctor() in D:\Source\Repos\Core\LedgerscopeWeb\LedgerscopeWeb\Admin.BackupSnapshotsController.generated.cs:line 0
   at T4MVC.AdminClass..ctor() in D:\Source\Repos\Core\LedgerscopeWeb\LedgerscopeWeb\T4MVC.cs:line 105
   at MVC..cctor() in D:\Source\Repos\Core\LedgerscopeWeb\LedgerscopeWeb\T4MVC.cs:line 64
   --- End of inner exception stack trace ---
   at MVC.get_Admin()
   at LedgerscopeWeb.Areas.Admin.Controllers.BackupSnapshotsController.ForBackup(JobId parentBackupJobId) in D:\Source\Repos\Core\LedgerscopeWeb\LedgerscopeWeb\Areas\Admin\Controllers\BackupSnapshotsController.cs:line 70
   at LedgerscopeWeb.UnitTests.Areas.Admin.BackupSnapshotsControllerTests.ForBackup_Should_Call_GetFullBackupJob_On_FullBackupJobConstructor_With_Correct_Arguments() in D:\Source\Repos\Core\LedgerscopeWeb\LedgerscopeWeb.Tests\Areas\Admin\BackupSnapshotsControllerTests.cs:line 122


T4MVC.cs has "//ncrunch: no coverage start" on line 28, and Admin.BackupSnapshotsController.generated.cs has it on line 26. There is no code in either of these files before those lines, only using statements

I'm happy to privately send you these files if it will help at all, but the only thing I can think of is that the T4MVC.cs file has multiple "top level" namespaces in it, so could it be that the "no coverage start" automatically ends when it gets to a namespace end?
Back to top
Remco
#6 Posted : Thursday, August 22, 2019 11:56:30 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,976

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
I think it's possible that the blocking of code coverage is only reliably effective here from line 1 of the file, as line 0 would sit before the '//ncrunch: no coverage start', so probably the instrumentor is still processing line 0.

In which case we likely have no option here other than to turn off instrumention for the entire assembly. It's possible the intermittency of the error is due to the declaration sequence of items in the assembly.
Back to top
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.046 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download