There may be a simple solution to the underlying problem here, but the behavior has me kind of spooked.
The description is pretty simple: One routine creates classes and puts them into a list. I have IComparer(of T) implemented for the class so that I can sort the objects in the list based on one field, which happens to be a date field. When I run the program with no breakpoints, I get an error message at a certain (repeatable) location that states that one pair failed to compare. At that time, I can look at the list, and see that it has two items. The second item is clearly malformed, and has no date. Since the date is bad, that is most likely why the error is showing up.
Therefore, I went looking at the routine that creates these classes to build the list so that I could see how a malformed object was being added to the list. To do this, I put a breakpoint just before the routine that builds the classes. This is all done in a loop, so I am able to see that things are done correctly up until a certain object is built, and that is the one that fails. All of this is very standard debugging procedures that anyone might recognize.
Here's the part that has me spooked: When I step through the code, the object is built correctly, and has the correct date. The sorting of the list still fails, and fails with the same error message, but in this case the objects in the list are both correct. In other words, if I don't step through the code, a malformed object is added to the list (all properties are Null or default values, which would be impossible in the constructor of the object). If I step through the code, the object is well-formed with all properties having valid values. In both cases, sorting on the date field doesn't work. When the object is malformed, I'm not surprised that sorting fails, as the sort field never gets set to anything, but when I step through the code, the field is set to something and sorting still fails.
What really has me disturbed is that the object is well formed if I step through the code, but malformed if I let it run without a breakpoint. This started yesterday, and VS was clearly flaking out on me, so I quit for the day. Unfortunately, the same behavior is happening today, but VS is working otherwise flawlessly.
Clearly there is an underlying bug in the program, because the code is in a loop, and the loop proceeds through several iterations before hitting this one iteration where it breaks. Furthermore, since it is always breaking in the exact same place and exact same way, there is a clear culprit. The fact that the behavior is different when I step through it versus running the code is what has me really disturbed.
The description is pretty simple: One routine creates classes and puts them into a list. I have IComparer(of T) implemented for the class so that I can sort the objects in the list based on one field, which happens to be a date field. When I run the program with no breakpoints, I get an error message at a certain (repeatable) location that states that one pair failed to compare. At that time, I can look at the list, and see that it has two items. The second item is clearly malformed, and has no date. Since the date is bad, that is most likely why the error is showing up.
Therefore, I went looking at the routine that creates these classes to build the list so that I could see how a malformed object was being added to the list. To do this, I put a breakpoint just before the routine that builds the classes. This is all done in a loop, so I am able to see that things are done correctly up until a certain object is built, and that is the one that fails. All of this is very standard debugging procedures that anyone might recognize.
Here's the part that has me spooked: When I step through the code, the object is built correctly, and has the correct date. The sorting of the list still fails, and fails with the same error message, but in this case the objects in the list are both correct. In other words, if I don't step through the code, a malformed object is added to the list (all properties are Null or default values, which would be impossible in the constructor of the object). If I step through the code, the object is well-formed with all properties having valid values. In both cases, sorting on the date field doesn't work. When the object is malformed, I'm not surprised that sorting fails, as the sort field never gets set to anything, but when I step through the code, the field is set to something and sorting still fails.
What really has me disturbed is that the object is well formed if I step through the code, but malformed if I let it run without a breakpoint. This started yesterday, and VS was clearly flaking out on me, so I quit for the day. Unfortunately, the same behavior is happening today, but VS is working otherwise flawlessly.
Clearly there is an underlying bug in the program, because the code is in a loop, and the loop proceeds through several iterations before hitting this one iteration where it breaks. Furthermore, since it is always breaking in the exact same place and exact same way, there is a clear culprit. The fact that the behavior is different when I step through it versus running the code is what has me really disturbed.