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

Notification

Icon
Error
Local variables unavailable when debugging
Options
Previous Topic Next Topic
willdean
#1 Posted : Friday, May 18, 2012 10:49:35 AM(UTC)
Rank: Member

Groups: Registered
Joined: 1/31/2012(UTC)
Posts: 27
Location: England

Thanks: 7 times
Was thanked: 2 time(s) in 2 post(s)

(It should go without saying that I'm a big fan of nCrunch - always looking for the latest version, and running 1.39b at the moment.)

An irritating problem I'm having with nCrunch is that local variables are not always available when debugging via nCrunch, apparently because the JIT is running in a full optimising mode, which has discarded some locals. This seems something to do with the debug execution environment, rather than the compilation environment.

I have tried adding a nCrunch.TaskRunner40.x86.ini file in the same directory as the nCrunch .exes, with

[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

but this hasn't improved things (to my surprise, really - I have checked the .INI is being read)

My code is definitely being built with all the DEBUG options, and if I use the Resharper test runner to debug into the test, everything's available.

I'm not clear if this is something to do with the fact that the TaskRunner .exes are optimised, or something to do with nCrunch starting runner processes and then attaching a debugger later. It would be great to find some way to improve this though (I am happy to try things at this end if you have any suggestions, or could send me a debug-built TaskRunner exe.

I have tried and failed to create a simple test case which shows this optimised-away local variable problem, though inevitably it seems to apply to almost every variable I want to look at in real production code...

Thanks,

Will
Back to top
Remco
#2 Posted : Saturday, May 19, 2012 12:28:07 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Hi Will,

Thanks for posting about this issue and I agree that it's a cause for frustration.

NCrunch does have a known issue at the moment around some of its manipulation of PDB files and this is known to cause some problems with the debugger, though I don't think this should be affecting local variables. It would be great if I could learn a little more about your codebase so as to stand a chance of reproducing this issue locally.

Which language are you working with at the moment? Is it C#?

Have you noticed any particular pattern within your solution around which projects are affected by the issue?

When you're unable to access local variables using the debugger, are you still able to access global static members and type references within the application domain?

Does the problem go away if you turn off the 'Analyse line execution times' option in your NCrunch project configuration?


Thanks!

Remco
Back to top
willdean
#3 Posted : Thursday, May 24, 2012 1:49:23 PM(UTC)
Rank: Member

Groups: Registered
Joined: 1/31/2012(UTC)
Posts: 27
Location: England

Thanks: 7 times
Was thanked: 2 time(s) in 2 post(s)
Remco;1908 wrote:

NCrunch does have a known issue at the moment around some of its manipulation of PDB files and this is known to cause some problems with the debugger, though I don't think this should be affecting local variables. It would be great if I could learn a little more about your codebase so as to stand a chance of reproducing this issue locally.

Which language are you working with at the moment? Is it C#?

Have you noticed any particular pattern within your solution around which projects are affected by the issue?

When you're unable to access local variables using the debugger, are you still able to access global static members and type references within the application domain?

Does the problem go away if you turn off the 'Analyse line execution times' option in your NCrunch project configuration?



Remco - sorry for the delay - in order:

* C#, VS2010 SP1, 64-bit machine
* Seems to be every time I want to inspect a local variable, unless I'm trying to create a repro ;-) Seriously though, I can't see a pattern, but it's a very common problem.
* Interestingly, I just added a static string[] field to the same class I've been testing in, and no I can't inspect that either
* No turning off "analyse line execution times" didn't make any difference

Other data:

* The 'modules' window in the debugger shows the test and under-test DLLs as non-optimised, and with symbols loaded correctly.
* In the 'real' bin\debug directory, the dll is 51K and its PDB file is 186K. In the ncrunch directory, the DLL is 71K and the PDB is 164K. (larger DLL, smaller PDB)

I can probably send the whole solution to you if it's useful.

Thanks,

Will
Back to top
Remco
#4 Posted : Thursday, May 24, 2012 10:17:24 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Hi Will -

If it's possible, I'd really like to have a look at the solution. I'll DM you with some contact information so we can discuss it offline.


Thanks!

Remco
Back to top
Remco
#5 Posted : Friday, May 25, 2012 9:36:53 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
For anyone interested, Will helped me to reproduce this problem and I was able to confirm that it was related to the manner in which the C# compiler handles the 'yield' statement. I'm currently looking into ways in which this can be fixed. To reduce the scope of the problem, it's recommended you try to isolate usage of the yield statement to the smallest methods possible.
Back to top
topdownjohnny
#6 Posted : Wednesday, February 6, 2013 2:02:52 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/6/2012(UTC)
Posts: 7
Remco,

I saw that this problem still exists (in 1.44, VS2012). Is it still on your radar?

John Landheer
Back to top
Remco
#7 Posted : Wednesday, February 6, 2013 9:01:55 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Hi John -

This one is definitely still on the radar, although I've yet to find a way of fixing it. There is some kind of inference in the VS debugger that identifies compiler generated code blocks (such as yield), and NCrunch's instrumentation interferes with it. I'll keep looking, but its starting to seem more and more like this issue may be unfixable in the short term ... there's just too much magic involved.
Back to top
eriove
#8 Posted : Wednesday, May 10, 2017 7:02:01 PM(UTC)
Rank: Member

Groups: Registered
Joined: 3/22/2016(UTC)
Posts: 21
Location: Sweden

Thanks: 14 times
Was thanked: 2 time(s) in 2 post(s)
I started running into this problem a couple of days ago (latest version of VS2017 and nCrunch). Is there anything in particular I can do to avoid it except not using yield return? Would it help if you got more projects with the problem?
Back to top
Remco
#9 Posted : Wednesday, May 10, 2017 10:09:53 PM(UTC)
Rank: NCrunch Developer

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

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

Sorry to leave this thread hanging, but this problem was actually resolved in a build quite some time ago. It's likely you've encountered something different. Are you able to share any examples of the code that seems to suppress variable data at debug time? If I can reconstruct the problem, I may be able to analyse it further.
Back to top
eriove
#10 Posted : Thursday, May 18, 2017 7:03:56 AM(UTC)
Rank: Member

Groups: Registered
Joined: 3/22/2016(UTC)
Posts: 21
Location: Sweden

Thanks: 14 times
Was thanked: 2 time(s) in 2 post(s)
Hi,

No problem. I haven't managed to reproduce it in a small solution. Only in our 80 project solution. However I get this error message when trying to look at "this" in the watch window:

error CS1705: Assembly 'aaa.bbb..UnitTests' with identity 'aaa.bbb.UnitTests, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' uses 'xunit.core, Version=2.2.0.3545, Culture=neutral, PublicKeyToken=8d05b1bb7a6fdb6c' which has a higher version than referenced assembly 'xunit.core' with identity 'xunit.core, Version=2.1.0.3179, Culture=neutral, PublicKeyToken=8d05b1bb7a6fdb6c'

When searching for xunit.core.dll I found the older version in some of the project folders. Those projects targeted .NET 4.5 and not 4.6 and where referencing xunit without package references. After upgrading them to 4.6 and adding NuGet references with the latest I searched for the old xunit dlls and couldn't find them in the ncrunch working folder.

My next step would be to use ProcessMonitor to see where the old xunit.core is located and delete it. I hope to have time to try that in the beginning of next week.
Back to top
Remco
#11 Posted : Thursday, May 18, 2017 7:31:57 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
NCrunch ships with xunit v2.1, which is usually found at C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Remco Software\NCrunch for Visual Studio 2017\Modules\XUnit2.

There are plans to upgrade it to xunit v2.2, which will involve some integration changes to do properly. However, it may well work to simply update the xunit binaries sitting in the above directory to v2.2, as these will likely work in your use case and may well solve the problem you're experiencing.

NCrunch will always ignore the version of xunit you are referencing and will use its own packaged version instead. This will change with the v2.2 integration (where I hope to then have it using your referenced version instead of it's own).
Back to top
1 user thanked Remco for this useful post.
eriove on 5/18/2017(UTC)
eriove
#12 Posted : Thursday, May 18, 2017 7:48:49 AM(UTC)
Rank: Member

Groups: Registered
Joined: 3/22/2016(UTC)
Posts: 21
Location: Sweden

Thanks: 14 times
Was thanked: 2 time(s) in 2 post(s)
I tried replacing the files. It still uses the older xunit dll. Will investigate more next week.
Back to top
eriove
#13 Posted : Friday, June 9, 2017 11:40:12 AM(UTC)
Rank: Member

Groups: Registered
Joined: 3/22/2016(UTC)
Posts: 21
Location: Sweden

Thanks: 14 times
Was thanked: 2 time(s) in 2 post(s)
After a couple of restarts of the computer and then it started working. With the latest release (3.9) I've reverted to the files installed by nCrunch and it still works.
Back to top
Remco
#14 Posted : Friday, June 9, 2017 11:45:59 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
eriove;10563 wrote:
After a couple of restarts of the computer and then it started working. With the latest release (3.9) I've reverted to the files installed by nCrunch and it still works.


NCrunch v3.9 introduced more structurally correct integration with Xunit2, so I hope we should no longer be seeing Xunit version released issues. Thanks for confirming all is well!
Back to top
1 user thanked Remco for this useful post.
eriove on 6/9/2017(UTC)
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.080 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download