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

Notification

Icon
Error

Error StackTrace is not navigatable when instrumentation is off
Konstantin Spirin
#1 Posted : Sunday, March 22, 2015 1:46:01 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/22/2015(UTC)
Posts: 2
Location: Singapore

Hi,

If I off assembly instrumentation then stack traces don't contain clickable links. This is quite inconvenient as I need maximum execution performance and ability to navigate to errors with mouse clicking is always better than browsing stack trace manually.

Is it possible to get the best of both worlds?

Regards,
Konstantin.
Remco
#2 Posted : Sunday, March 22, 2015 9:43:07 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 862 times
Was thanked: 1176 time(s) in 1097 post(s)
Hi Konstantin,

I'm afraid not. The instrumentation contains an important step that rewrites the assembly's debug information so that source lines point back to the foreground solution (instead of the workspace). Without this step, NCrunch won't be able to reconcile the physical navigation entries with the source code you have open inside the IDE.


Cheers,

Remco
Konstantin Spirin
#3 Posted : Monday, March 23, 2015 1:39:19 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/22/2015(UTC)
Posts: 2
Location: Singapore

With instrumentation:
Quote:
System.IndexOutOfRangeException: Index was outside the bounds of the array.
at SingingEasy.sing(Int32 cur3, Int32 prevAliceIndex2, Int32 prevBobIndex2) in C:\TopCoder\SingingEasy.cs:line 26
at SingingEasy.solve(Int32[] pitch) in C:\TopCoder\SingingEasy.cs:line 41
at Tests.TestAll() in C:\TopCoder\SingingEasy.cs:line 63


Without instrumentation:
Quote:
System.IndexOutOfRangeException: Index was outside the bounds of the array.
at SingingEasy.sing(Int32 cur3, Int32 prevAliceIndex2, Int32 prevBobIndex2) in c:\Users\kaspir\AppData\Local\NCrunch\10692\37\SingingEasy.cs:line 26
at SingingEasy.solve(Int32[] pitch) in c:\Users\kaspir\AppData\Local\NCrunch\10692\37\SingingEasy.cs:line 41
at Tests.TestAll() in c:\Users\kaspir\AppData\Local\NCrunch\10692\37\SingingEasy.cs:line 63


The difference is in base paths:
- "c:\Users\kaspir\AppData\Local\NCrunch\10692\37\"
- "C:\TopCoder\" <-- this is the desired path

The output window could instead of highlighting the whole C:\TopCoder\SingingEasy.cs:line 41 only highlight relative path SingingEasy.cs:line 41 and on click navigate to the correct c:\TopCoder\SingingEasy.cs:line 41 regardless of the base path.

Hopefully it is possible to implement this.
Remco
#4 Posted : Monday, March 23, 2015 11:03:00 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 862 times
Was thanked: 1176 time(s) in 1097 post(s)
Konstantin Spirin;7101 wrote:

The difference is in base paths:
- "c:\Users\kaspir\AppData\Local\NCrunch\10692\37\"
- "C:\TopCoder\" <-- this is the desired path

The output window could instead of highlighting the whole C:\TopCoder\SingingEasy.cs:line 41 only highlight relative path SingingEasy.cs:line 41 and on click navigate to the correct c:\TopCoder\SingingEasy.cs:line 41 regardless of the base path.

Hopefully it is possible to implement this.


This is correct. The paths given during the error will point to the workspace. Unfortunately, the fix isn't as simple as just swapping the paths to be relative. All paths must be absolute, so NCrunch would need to parse them out and re-write them. This means parsing to be performed over the top of all test and build output (which can be surprisingly expensive given the amount of output some tests kick out). It also creates room for the parsing to fail, thus corrupting the actual data and causing confusion. Basically it means masking/manipulating output from tests and builds to make it appear different, which is something I try very hard to avoid doing.

It would also mean bringing more information about all the workspace file mappings up through the engine, which would bring more complexity and loss in performance.

All this would also be implemented as a fallback, since the primary way such a situation is handled is still through the instrumentation remapping debug data, which works well in almost all cases.

Basically, what I'm trying to say is that at the moment this feature wouldn't be worth the complexity and potential loss in performance required to implement it, unless the lost path linking is impacting many people and there is a strong collective movement towards getting it fixed. You're welcome to vote for it as a feature if you like. If enough people are being hit by this, I may be able to justify implementing a solution.
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.040 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download