Weird Debugging Problem
-
I originally created a project in VS2008, converted it to VS2010. Last night, I decided I didn't want to continue using VS2010. I then created a new project in VS2008, and copied all of the code from the original project into it. Everything compiles just fine, but the app didn't work like it did before the latest conversion, so I started up a debug session, and immediately found the problem. When the app starts up, it fires off a
BackgroundWorkerobject. The worker processes as normal, but when it jumps into theReportProgressevent handler,the first line of code is anifstatement. It appears as if theifstatement isn't being evaluated at all (I put anelseclause in to see, and it's not being stepped into at all), and control is immediately returned to theRunWorkerevent handler. What could I have done to the code that could possibly cause this? Of course, I've tried the obvious remedy (clean/rebuild), but it didn't work..45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
I originally created a project in VS2008, converted it to VS2010. Last night, I decided I didn't want to continue using VS2010. I then created a new project in VS2008, and copied all of the code from the original project into it. Everything compiles just fine, but the app didn't work like it did before the latest conversion, so I started up a debug session, and immediately found the problem. When the app starts up, it fires off a
BackgroundWorkerobject. The worker processes as normal, but when it jumps into theReportProgressevent handler,the first line of code is anifstatement. It appears as if theifstatement isn't being evaluated at all (I put anelseclause in to see, and it's not being stepped into at all), and control is immediately returned to theRunWorkerevent handler. What could I have done to the code that could possibly cause this? Of course, I've tried the obvious remedy (clean/rebuild), but it didn't work..45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001Have you tried writing a trace to the output window from the
ReportProgressevent handler? There is probably something going on with the threading possibly the debugger isn't picking up the call to the handler due to a different thread being used. I think it likely that VS2010 uses a different thread model to VS2008, being built using WPF, you might even have discovered a genuine bug in the VS2010 beta...CCC solved so far: 2 (including a Hard One!) 37!?!! - Randall, Clerks
-
I originally created a project in VS2008, converted it to VS2010. Last night, I decided I didn't want to continue using VS2010. I then created a new project in VS2008, and copied all of the code from the original project into it. Everything compiles just fine, but the app didn't work like it did before the latest conversion, so I started up a debug session, and immediately found the problem. When the app starts up, it fires off a
BackgroundWorkerobject. The worker processes as normal, but when it jumps into theReportProgressevent handler,the first line of code is anifstatement. It appears as if theifstatement isn't being evaluated at all (I put anelseclause in to see, and it's not being stepped into at all), and control is immediately returned to theRunWorkerevent handler. What could I have done to the code that could possibly cause this? Of course, I've tried the obvious remedy (clean/rebuild), but it didn't work..45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001I've only seen this kind of thing when the debug data gets "out of sync" with the source code, and it is usually resolved by doing a re-build. However, if the project is in Release Configuration rather than Debug Configuration, then optimizations in the build could be causing it to skip the code. The thing is, it usually only skips code that it determines will never be executed. I would ensure that you are working in Debug Configuration and check the values that the if statement tests as soon as it enters the event handler. If you think the compiler is errantly determining that statement to be unnecessary and optimizing it out; stick "
true &&" at the front of it to force the statement to resolve to true and then re-build and re-run the code.Hold on a second here... Don't you think you might be putting the horse ahead of the cart?
-
I've only seen this kind of thing when the debug data gets "out of sync" with the source code, and it is usually resolved by doing a re-build. However, if the project is in Release Configuration rather than Debug Configuration, then optimizations in the build could be causing it to skip the code. The thing is, it usually only skips code that it determines will never be executed. I would ensure that you are working in Debug Configuration and check the values that the if statement tests as soon as it enters the event handler. If you think the compiler is errantly determining that statement to be unnecessary and optimizing it out; stick "
true &&" at the front of it to force the statement to resolve to true and then re-build and re-run the code.Hold on a second here... Don't you think you might be putting the horse ahead of the cart?
true ||? :)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
Merry Christmas and a Happy New Year to all.
-
I've only seen this kind of thing when the debug data gets "out of sync" with the source code, and it is usually resolved by doing a re-build. However, if the project is in Release Configuration rather than Debug Configuration, then optimizations in the build could be causing it to skip the code. The thing is, it usually only skips code that it determines will never be executed. I would ensure that you are working in Debug Configuration and check the values that the if statement tests as soon as it enters the event handler. If you think the compiler is errantly determining that statement to be unnecessary and optimizing it out; stick "
true &&" at the front of it to force the statement to resolve to true and then re-build and re-run the code.Hold on a second here... Don't you think you might be putting the horse ahead of the cart?
Well, it's a completely new project created in VS2008, and I only added the source files back to the project. I know for a fact there aren't any PCB files or other temporary files form VS2010 because of the way the project was created, so I'm not sure how the debug info can be out of sync. I also verified that the project is indeed being compiled in debug mode. The
**if**statement isn't evaluated at all. The debugger hits that statement, and then goes right back to the runworker event handler. I suspect that putting**true ||**in front of the existing expression wouldn't have any effect, but when I get home, I'll try it..45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
true ||? :)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
Merry Christmas and a Happy New Year to all.
-
I originally created a project in VS2008, converted it to VS2010. Last night, I decided I didn't want to continue using VS2010. I then created a new project in VS2008, and copied all of the code from the original project into it. Everything compiles just fine, but the app didn't work like it did before the latest conversion, so I started up a debug session, and immediately found the problem. When the app starts up, it fires off a
BackgroundWorkerobject. The worker processes as normal, but when it jumps into theReportProgressevent handler,the first line of code is anifstatement. It appears as if theifstatement isn't being evaluated at all (I put anelseclause in to see, and it's not being stepped into at all), and control is immediately returned to theRunWorkerevent handler. What could I have done to the code that could possibly cause this? Of course, I've tried the obvious remedy (clean/rebuild), but it didn't work..45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
Well, it's a completely new project created in VS2008, and I only added the source files back to the project. I know for a fact there aren't any PCB files or other temporary files form VS2010 because of the way the project was created, so I'm not sure how the debug info can be out of sync. I also verified that the project is indeed being compiled in debug mode. The
**if**statement isn't evaluated at all. The debugger hits that statement, and then goes right back to the runworker event handler. I suspect that putting**true ||**in front of the existing expression wouldn't have any effect, but when I get home, I'll try it..45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001Did you manipulate the
BackgroundWorkerthrough the designer in VS2010? If so, it may have added some funky code to the .designer.cs file. Just a thought...Hold on a second here... Don't you think you might be putting the horse ahead of the cart?
-
Well, it's a completely new project created in VS2008, and I only added the source files back to the project. I know for a fact there aren't any PCB files or other temporary files form VS2010 because of the way the project was created, so I'm not sure how the debug info can be out of sync. I also verified that the project is indeed being compiled in debug mode. The
**if**statement isn't evaluated at all. The debugger hits that statement, and then goes right back to the runworker event handler. I suspect that putting**true ||**in front of the existing expression wouldn't have any effect, but when I get home, I'll try it..45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001I've read your OP properly and understand that you've take a project back to VS2008 :doh: . The PDB sync is the first problem that I've encountered that might cause your error. I've had problems with clean in the past, and had to manually clear out all the BIN directories. I'd go to the extent of deleting all build "flavour" directories (bin\debug \bin\live etc). This has two effects: The PDB must be in sync; and, as has happened to me in the past, a Solution "debug" build had "live" builds hidden away in the the Configuration Manager. If you do a debug build and have anything other than debug sub-directories in your bin folder, this might be your culprit. The only other time I've seen this problem was when an exception was raised on another thread (the UI thread in my case), and a top level exception handler caught it without reporting. To find this, switch on break on all exceptions.
CCC solved so far: 2 (including a Hard One!) 37!?!! - Randall, Clerks
modified on Tuesday, December 29, 2009 10:00 AM
-
Did you manipulate the
BackgroundWorkerthrough the designer in VS2010? If so, it may have added some funky code to the .designer.cs file. Just a thought...Hold on a second here... Don't you think you might be putting the horse ahead of the cart?
Nope - manually added.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
I've read your OP properly and understand that you've take a project back to VS2008 :doh: . The PDB sync is the first problem that I've encountered that might cause your error. I've had problems with clean in the past, and had to manually clear out all the BIN directories. I'd go to the extent of deleting all build "flavour" directories (bin\debug \bin\live etc). This has two effects: The PDB must be in sync; and, as has happened to me in the past, a Solution "debug" build had "live" builds hidden away in the the Configuration Manager. If you do a debug build and have anything other than debug sub-directories in your bin folder, this might be your culprit. The only other time I've seen this problem was when an exception was raised on another thread (the UI thread in my case), and a top level exception handler caught it without reporting. To find this, switch on break on all exceptions.
CCC solved so far: 2 (including a Hard One!) 37!?!! - Randall, Clerks
modified on Tuesday, December 29, 2009 10:00 AM
You didn't read the whole message. I created a BRAND NEW project in VS2008 and moved the source code to it, and re-added the appropriate references to the new project. There were no PDB files brought over, and certainly no project files. As far as it knows, it began life as a VS2008 project.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
It may be stupied question, does the
ReportProgressEvent fire at all?Yes - go back and read the original message. The debugger steps into the event handler but the if statement but immediately returns control to the runworker event handler, apparently without evaluating the if statement *at all*.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
You didn't read the whole message. I created a BRAND NEW project in VS2008 and moved the source code to it, and re-added the appropriate references to the new project. There were no PDB files brought over, and certainly no project files. As far as it knows, it began life as a VS2008 project.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001John Simmons / outlaw programmer wrote:
You didn't read the whole message.
Actually I did. You are looking for possible causes to your problem everything I described in my last post has thrown up the problem you described in you OP for me in the past (without VS2010 being involved) : a) Generally bad PDB synchronisation will cause the symptoms you describe. If you have built more than once (even with a new project), you might have bad PDB, without carrying over the ones from 2010. Clean sometimes doesn't do its job properly (at least in my experience), so a manual deletion might help. b) I have also seen the exact error you describe because some turnip on my team changed the solution-level "debug" build configuration so it built one of the many projects under its live build. In this case the debugger was hooking into a PDB for the last debug build of that dll, again causing synchronisation problems with the code. You can spot this quickly by doing what I described in step a, and my last post. c) I had a problem where the debugger apparently did not evaluate the line of code I had a breakpoint on (actuall, an if statement like yours as it happens).An exception was being thrown by another thread (the UI thread in my case) causing the thread running the code being debugged to be terminated, but it looked like the line of code in the debugger was not being evaluated (as you described). This one is a long-shot, but is easily spotted by getting the debugger to break on all thrown CLR Exceptions, not just the caught ones.
CCC solved so far: 2 (including a Hard One!) 37!?!! - Randall, Clerks
-
I originally created a project in VS2008, converted it to VS2010. Last night, I decided I didn't want to continue using VS2010. I then created a new project in VS2008, and copied all of the code from the original project into it. Everything compiles just fine, but the app didn't work like it did before the latest conversion, so I started up a debug session, and immediately found the problem. When the app starts up, it fires off a
BackgroundWorkerobject. The worker processes as normal, but when it jumps into theReportProgressevent handler,the first line of code is anifstatement. It appears as if theifstatement isn't being evaluated at all (I put anelseclause in to see, and it's not being stepped into at all), and control is immediately returned to theRunWorkerevent handler. What could I have done to the code that could possibly cause this? Of course, I've tried the obvious remedy (clean/rebuild), but it didn't work..45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001Interesting. I would decompile it of course. I would also put a break point in to stop before it gets to the 'if' in question. Then click the decompile button in VS2008 and try stepping through the machine code. The comment about using inline debugging statements is a good one. I would like to hear what the result is once you find the solution, I'm book marking this thread. Thanks John...
