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

Notification

Icon
Error

Stacktrace issues with code contracts on abstract methods
shiranpuri
#1 Posted : Saturday, March 9, 2013 5:16:13 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/9/2013(UTC)
Posts: 7

Thanks: 1 times
Occasionally I run into a mismatch of line numbers and filenames, (the line number is correct, but the filename isn't), and it differs from the stacktrace provided when running it without ncrunch.
I'm running ncrunch 1.44.0.11 in vs2012 update 1 on windows 8; the following code (with mstest) causes the problem for me:

Parent.cs:
Code:
namespace UnitTestProject
{
    using System.Diagnostics.Contracts;

    [ContractClass(typeof(ParentContracts))]
    public abstract class Parent
    {
        public abstract void ChildThrowsException();
    }

    [ContractClassFor(typeof(Parent))]
    public class ParentContracts : Parent
    {
        public override void ChildThrowsException()
        {
            Contract.Requires(true);
        }
    }
}


UnitTest.cs:
Code:
namespace UnitTestProject
{
    using System.Diagnostics.Contracts;

    [ContractClassFor(typeof(Parent))]
    public class ParentContracts : Parent
    {
        public override void ChildThrowsException()
        {
            Contract.Requires(true);
        }
    }

    [ContractClass(typeof(ParentContracts))]
    public abstract class Parent
    {
        public abstract void ChildThrowsException();
    }
}


Running it in ncrunch gives me the following stacktrace:
Code:
System.Exception: Exception of type 'System.Exception' was thrown.
   at UnitTestProject.Child.ChildThrowsException() in D:\CSharpConsoleSandBox\UnitTestProject\Parent.cs:line 10#0
   at UnitTestProject.UnitTest.TestMethod1() in D:\CSharpConsoleSandBox\UnitTestProject\UnitTest.cs:line 21#1


Along with this, navigation and markers don't work properly. The marker and navigation match the above stacktrace, so it takes me to the wrong file/line, and shows an 'x' on the line indicated in the stack trace (if possible/there happens to be a line of executable code there).
The line the exception was really thrown is indicated as being hit by code coverage, but not part of the exception path (filled red circle).

Running it in vs's test runner gives me the following stacktrace: (note the different filenames)
Code:
System.Exception: Exception of type 'System.Exception' was thrown.
Result StackTrace:	
at UnitTestProject.Child.ChildThrowsException() in d:\CSharpConsoleSandBox\UnitTestProject\UnitTest.cs:line 10
   at UnitTestProject.UnitTest.TestMethod1() in d:\CSharpConsoleSandBox\UnitTestProject\UnitTest.cs:line 21



If I move the ParentContracts class into the same file as the Child class, the files and line numbers match up in the stacktrace, and the navigation and line markers match up properly also.
If I remove the Contract.Requires(true); line above, or disable runtime contract checking (so cc's rewriter doesn't add any code that's really in ParentContracts to Child's method), the problem goes away then also.
Remco
#2 Posted : Saturday, March 9, 2013 10:26:32 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Hi, thanks for posting!

There's quite a lot going on here. I've tried to build a sample solution to reproduce the issue you've described above, although unfortunately the stack traces seem to be correct for me. Do you have an example solution I could get hold of? I'd like to look at this issue a bit deeper. If so, can you zip it up and send it through the contact us form?


Thanks!

Remco
1 user thanked Remco for this useful post.
shiranpuri on 3/10/2013(UTC)
shiranpuri
#3 Posted : Sunday, March 10, 2013 1:14:32 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/9/2013(UTC)
Posts: 7

Thanks: 1 times
I uploaded the project along with some screenshots and dumps of what I'm seeing.
Remco
#4 Posted : Sunday, March 10, 2013 8:06:02 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Thanks for sending through the solution. I've tested against it, but even when using the same version of NCrunch on this solution, the stacktrace still shows the correct references for me.

This suggests that the problem is being triggered by something in your environment. Do you have access to a different workstation that you can test on? Or is there anything installed on your machine that might somehow impact the behaviour of Code Contracts or debug information?
shiranpuri
#5 Posted : Sunday, March 10, 2013 5:08:15 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/9/2013(UTC)
Posts: 7

Thanks: 1 times
I spun up a windows 7 vm and installed vs2012, the latest code contracts (from visualstudiogallery - was 1.4.60301.15 even tho the web page lists 1.4.60221.11), the latest ncrunch (1.44.0.11), and loaded+resynchronized+rebuilt+retested the test project I provided.

The same behavior is showing itself on my vm as on my main box.

I ran some more checks: (resynchronizing and re-running the tests with ncrunch between changes)

Any of the following scenarios give me the "expected" stacktrace in ncrunch:
(If the rewriter didn't run at all, it'd still give the expected stacktrace in this test project because none of the cc code gets hit - normally it'd hit other cc code and throw an exception there)

  • Code contracts is not installed (rewriter does not run)
  • "Perform Runtime Contract Checking" unticked (vs/cc setting - rewriter does not run)
  • "Perform Runtime Contract Checking" set to none (vs/cc setting - rewriter runs, but removes the code contracts code)
  • "Allow dynamic code contract checking" set to false (ncrunch setting)
  • "Instrument output assembly" set to false (ncrunch setting)

I also tried the comments to suppress code coverage for the blocks of code being hit, but couldn't get it to have an effect on the stacktrace - not sure if I was doing something wrong, or if the instrumentation suppression can even be applied in this case, between cc rewriting the code and ncrunch's instrumentation.

Anything else I can try that might help narrow down the problem?
Remco
#6 Posted : Sunday, March 10, 2013 9:35:42 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
After running through this again and making some modifications to the code, this suddenly started happening for me. I'm not sure why it wasn't surfacing before - perhaps there is an intermittent element?

Anyway, after reproducing the issue, I can confirm that this is being caused by NCrunch's instrumentation interfering with the debug information injected by ccrewrite. I'll see if I can get a fix for this included in the 1.45 maintenance release.

Thanks for all your help in reporting and analysing the problem!


Cheers,

Remco
shiranpuri
#7 Posted : Tuesday, March 12, 2013 1:07:47 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/9/2013(UTC)
Posts: 7

Thanks: 1 times
Great! Thanks, that will be much appreciated.
Remco
#8 Posted : Saturday, March 30, 2013 9:41:45 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
For anyone interested, a fix for this problem has been introduced with the newly released version of NCrunch (v1.45).
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.070 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download