Off-Code Errors?
-
I just spent nearly 2 hours debugging my program, just to notice the problem was something as simple as a flat copy. And that even though all my business objects have a method that returns a deep copy of the current instance. I am using a BackgroundWorker to test several DBs and in the RunWorkerCompleted Event I run it again to test the next DB. I'm using the same object to report the result of completing work as I do to report progress. The problem was that in the ProgressChanged Event a ListView is updated and around the time the BackgroundWorker started testing a new DB, the errors of the DB last tested miraculously turned to 0; It took me well over half an hour to pinpoint the exact time when it happened because it wasn't during the RunWorkerCompleted Event, but just before that, when it was reporting the progress of the last Table to be tested on the first DB. The real headeache, which wasted nearly 1.5 hours of my time was, that it happened off-code, i.e. while I was debugging the ProgressChanged event, it happened between 2 lines of code which both had nothing to do with either the variable of the business object holding error count nor with the ListView. On the other hand, when debugging the DoWork event of the BackgroundWorker, it also did not happen when testing the last table of a DB, but had already changed by the time a new DB was being tested. I did fix it by passing deep copies to the ReportProgress and RunWorkerCompleted events, but I'm still not exactly sure just wtf had happened. The only thing I can imagine is that just before assigning the ListViewItem it's text, the BackgroundWorker had already changed the value. I was under the impression that an object passed as argument to and from a BackgroundWorker is a completely new instance and no flat copy, but apparently that's not the case. :doh:
-
I just spent nearly 2 hours debugging my program, just to notice the problem was something as simple as a flat copy. And that even though all my business objects have a method that returns a deep copy of the current instance. I am using a BackgroundWorker to test several DBs and in the RunWorkerCompleted Event I run it again to test the next DB. I'm using the same object to report the result of completing work as I do to report progress. The problem was that in the ProgressChanged Event a ListView is updated and around the time the BackgroundWorker started testing a new DB, the errors of the DB last tested miraculously turned to 0; It took me well over half an hour to pinpoint the exact time when it happened because it wasn't during the RunWorkerCompleted Event, but just before that, when it was reporting the progress of the last Table to be tested on the first DB. The real headeache, which wasted nearly 1.5 hours of my time was, that it happened off-code, i.e. while I was debugging the ProgressChanged event, it happened between 2 lines of code which both had nothing to do with either the variable of the business object holding error count nor with the ListView. On the other hand, when debugging the DoWork event of the BackgroundWorker, it also did not happen when testing the last table of a DB, but had already changed by the time a new DB was being tested. I did fix it by passing deep copies to the ReportProgress and RunWorkerCompleted events, but I'm still not exactly sure just wtf had happened. The only thing I can imagine is that just before assigning the ListViewItem it's text, the BackgroundWorker had already changed the value. I was under the impression that an object passed as argument to and from a BackgroundWorker is a completely new instance and no flat copy, but apparently that's not the case. :doh:
Well, just remember this next time you have do debug something like that :)
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
I just spent nearly 2 hours debugging my program, just to notice the problem was something as simple as a flat copy. And that even though all my business objects have a method that returns a deep copy of the current instance. I am using a BackgroundWorker to test several DBs and in the RunWorkerCompleted Event I run it again to test the next DB. I'm using the same object to report the result of completing work as I do to report progress. The problem was that in the ProgressChanged Event a ListView is updated and around the time the BackgroundWorker started testing a new DB, the errors of the DB last tested miraculously turned to 0; It took me well over half an hour to pinpoint the exact time when it happened because it wasn't during the RunWorkerCompleted Event, but just before that, when it was reporting the progress of the last Table to be tested on the first DB. The real headeache, which wasted nearly 1.5 hours of my time was, that it happened off-code, i.e. while I was debugging the ProgressChanged event, it happened between 2 lines of code which both had nothing to do with either the variable of the business object holding error count nor with the ListView. On the other hand, when debugging the DoWork event of the BackgroundWorker, it also did not happen when testing the last table of a DB, but had already changed by the time a new DB was being tested. I did fix it by passing deep copies to the ReportProgress and RunWorkerCompleted events, but I'm still not exactly sure just wtf had happened. The only thing I can imagine is that just before assigning the ListViewItem it's text, the BackgroundWorker had already changed the value. I was under the impression that an object passed as argument to and from a BackgroundWorker is a completely new instance and no flat copy, but apparently that's not the case. :doh:
Megidolaon wrote:
an object passed as argument
would be by reference, no?
-
I just spent nearly 2 hours debugging my program, just to notice the problem was something as simple as a flat copy. And that even though all my business objects have a method that returns a deep copy of the current instance. I am using a BackgroundWorker to test several DBs and in the RunWorkerCompleted Event I run it again to test the next DB. I'm using the same object to report the result of completing work as I do to report progress. The problem was that in the ProgressChanged Event a ListView is updated and around the time the BackgroundWorker started testing a new DB, the errors of the DB last tested miraculously turned to 0; It took me well over half an hour to pinpoint the exact time when it happened because it wasn't during the RunWorkerCompleted Event, but just before that, when it was reporting the progress of the last Table to be tested on the first DB. The real headeache, which wasted nearly 1.5 hours of my time was, that it happened off-code, i.e. while I was debugging the ProgressChanged event, it happened between 2 lines of code which both had nothing to do with either the variable of the business object holding error count nor with the ListView. On the other hand, when debugging the DoWork event of the BackgroundWorker, it also did not happen when testing the last table of a DB, but had already changed by the time a new DB was being tested. I did fix it by passing deep copies to the ReportProgress and RunWorkerCompleted events, but I'm still not exactly sure just wtf had happened. The only thing I can imagine is that just before assigning the ListViewItem it's text, the BackgroundWorker had already changed the value. I was under the impression that an object passed as argument to and from a BackgroundWorker is a completely new instance and no flat copy, but apparently that's not the case. :doh:
-
Megidolaon wrote:
an object passed as argument
would be by reference, no?
Strictly it's a reference, passed by value. I'm not actually a big fan of reference-based languages like VB, Java and C# for this reason. I'd rather the language made it clear that you're dealing with a reference/pointer, like in C++. In C# you have to know whether a type is a reference type (declared as a 'class') or a value type (declared as 'struct'). Arrays are always reference types whether the member type is a reference type or a value type. Strings in .NET are a reference type, but they're immutable so in many cases, you have to treat them as a value type (using 'out' and 'ref' to allow a called function to return a different string, for example).
DoEvents: Generating unexpected recursion since 1991
-
I just spent nearly 2 hours debugging my program, just to notice the problem was something as simple as a flat copy. And that even though all my business objects have a method that returns a deep copy of the current instance. I am using a BackgroundWorker to test several DBs and in the RunWorkerCompleted Event I run it again to test the next DB. I'm using the same object to report the result of completing work as I do to report progress. The problem was that in the ProgressChanged Event a ListView is updated and around the time the BackgroundWorker started testing a new DB, the errors of the DB last tested miraculously turned to 0; It took me well over half an hour to pinpoint the exact time when it happened because it wasn't during the RunWorkerCompleted Event, but just before that, when it was reporting the progress of the last Table to be tested on the first DB. The real headeache, which wasted nearly 1.5 hours of my time was, that it happened off-code, i.e. while I was debugging the ProgressChanged event, it happened between 2 lines of code which both had nothing to do with either the variable of the business object holding error count nor with the ListView. On the other hand, when debugging the DoWork event of the BackgroundWorker, it also did not happen when testing the last table of a DB, but had already changed by the time a new DB was being tested. I did fix it by passing deep copies to the ReportProgress and RunWorkerCompleted events, but I'm still not exactly sure just wtf had happened. The only thing I can imagine is that just before assigning the ListViewItem it's text, the BackgroundWorker had already changed the value. I was under the impression that an object passed as argument to and from a BackgroundWorker is a completely new instance and no flat copy, but apparently that's not the case. :doh:
I had a bug once where it would work perfectly when i debugged it, but failed when it ran normally. There was an issue with a thread running simotaniously and when i was debugging it, there was enough time for the processes to complete :)
Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. -Fred Brooks
-
I had a bug once where it would work perfectly when i debugged it, but failed when it ran normally. There was an issue with a thread running simotaniously and when i was debugging it, there was enough time for the processes to complete :)
Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. -Fred Brooks
I worked on a project where the product had a bug that only appeared in release mode... so we shipped the debug build. X|
-
I worked on a project where the product had a bug that only appeared in release mode... so we shipped the debug build. X|
:laugh: