A
Ayende Rahien
Warning, this is quite a big rant!
The story of a late night debugger:
The hour is 03:15 AM, and I'm sitting here satisfied. Another bug
eliminated, another enemy conquered. And this one is a tricky one.
I've created an application that loads Caudill's TreeListView as its
main UI. Now, my problem was that after I created about 50% of the
application, I decided to work on the start-up data load, and then the
application started to get nasty.
An IndexOutOfBoundException charged out of nowhere, directly into my
flanks. I was determined, however, and after donning my debugging
armor counter-attacked.
First, I traced the application to where it barfed, which wasn't nice,
it uses threads so it won't freeze (lot of network action).
Eventually I managed to track the error to a method which was adding
items to the TreeListView.
Now, that was strange, because the exact same code was working just a
few minutes ago when I was using it to insert items after the
application loaded.
I commented the line that called the insertion on start-up, and… woila
– everything works!
Then I knew that it wasn't going to be nice. Nevertheless, I set to
track the path of the enemy's army… err program execution, I mean.
I found out that I inserted items into the TreeListView before I added
columns to it. Aha, I thought, now I got it! Fixed this, compile and
run… but IndexOutOfBound has managed to sneak behind me again, leaving
me with no other option but following the entire execution path of the
program when I did manage to insert the items (on normal program
execution).
Tired and panting, I finished that battle, but I felt victorious, I
used the campaign to refactor my forces organization, and I was
certain that they would withstand any attack. But over-confidence was
my failing, for as I tried once more to head for the territories I
desired. I've tracked the traitor deep into the enemy lines, until I
could no longer follow without risking the dreaded disassembly. But I
thought I'd it now, I managed to reinterduce inserting the items
without adding columns, so I was confident that all will be fine.
The exception caught me unaware, leaving me frustrated and screaming.
Time to regroup and do some thinking, I thought, so I commented the
insertion on startup and tried invading again. But I stopped short,
afraid, for there was no opposition this route.
Now I knew that I'd a spy on my side, for something was very wrong.
Hungry for blood, I attempted to throw confusion in the enemy's lines
and checked the startup data.
I wondered… could it be… but the changes were made in the application,
shouldn't it betray me then?
Change the startup data to match exactly to that created in the
application and test.
Success, I'd a beachhead on the enemy's front.
But it was still too early to get cocky; I tried to change the startup
data again, and checked what this might cause.
Treason! Mayhem! The exception only struck if I tried to insert the
most important items.
But how could the enemy reveal that? The only difference I could see
that some of the items were selected (they were created and then
selected on previous, more successful campaigns).
Impossible, for such a small change to create such drastic
measurements! Yet I'd seen it with my own eyes.
Item. Checked = Group. Selected;
This was the traitor.
If Group. Selected was true, then I was for an unpleasant surprise
trying to insert.
But why should it make any difference?
I tested, commenting this line and sending scouts ahead. They returned
with glowing eyes, talking about a rich land, if only I could overcome
the treason in my own camp…
I could not get rid of the traitor; he was too dear to me, so I sent
him to the front, after the insertion occurred.
And a miracle occurred, my surprised attack was successful, and I had
scored the enemy lines in many fronts.
But there was still the matter of the traitor…
I sent him to the front with a small unit, and he excelled, and so I
slowly enlarged his command until I finally had so sent him a
lieutenant – and then disaster struck.
Again a flank attack, directly at my weak spot. And now I've located
the real tratior.
He was a small routine, meant to handle ItemCheck called from the
TreeListView, the problem with him was that he used this code:
Group add_grp = Messages.Items[e.Index].Tag as Group;
Apperantly, TreeListView (and ListView, its base) first call the
ItemCheck delegate when they get an item with Checked = true and only
afterward they add the item to their Item list.
So whenever this routine was called, it would generate an
IndexOutOfBoundException, I couldn't trace it to its real location
using StackTrace because I'm using threads to create a responsive UI.
Conclusions:
• Always have a UnhandledException and ThreadException handlers, that
could've saved me a long time, I just tested it, and it would've give
me the real stack trace of the error which would've enabled me to
solve this in a few minutes.
• I would've never caught on to this bug if I wasn't trying to
repreduce the problem and settle on the workaround.
• Debugging multi-threading code is fun as an excrise for the bored
mind.
• The only reason that I got this exception from the main thread was
that I was using Invoke to update the UI, otherwise, I was into more
trouble.
• That was a lovely way to spend the night, thank you very much.
The story of a late night debugger:
The hour is 03:15 AM, and I'm sitting here satisfied. Another bug
eliminated, another enemy conquered. And this one is a tricky one.
I've created an application that loads Caudill's TreeListView as its
main UI. Now, my problem was that after I created about 50% of the
application, I decided to work on the start-up data load, and then the
application started to get nasty.
An IndexOutOfBoundException charged out of nowhere, directly into my
flanks. I was determined, however, and after donning my debugging
armor counter-attacked.
First, I traced the application to where it barfed, which wasn't nice,
it uses threads so it won't freeze (lot of network action).
Eventually I managed to track the error to a method which was adding
items to the TreeListView.
Now, that was strange, because the exact same code was working just a
few minutes ago when I was using it to insert items after the
application loaded.
I commented the line that called the insertion on start-up, and… woila
– everything works!
Then I knew that it wasn't going to be nice. Nevertheless, I set to
track the path of the enemy's army… err program execution, I mean.
I found out that I inserted items into the TreeListView before I added
columns to it. Aha, I thought, now I got it! Fixed this, compile and
run… but IndexOutOfBound has managed to sneak behind me again, leaving
me with no other option but following the entire execution path of the
program when I did manage to insert the items (on normal program
execution).
Tired and panting, I finished that battle, but I felt victorious, I
used the campaign to refactor my forces organization, and I was
certain that they would withstand any attack. But over-confidence was
my failing, for as I tried once more to head for the territories I
desired. I've tracked the traitor deep into the enemy lines, until I
could no longer follow without risking the dreaded disassembly. But I
thought I'd it now, I managed to reinterduce inserting the items
without adding columns, so I was confident that all will be fine.
The exception caught me unaware, leaving me frustrated and screaming.
Time to regroup and do some thinking, I thought, so I commented the
insertion on startup and tried invading again. But I stopped short,
afraid, for there was no opposition this route.
Now I knew that I'd a spy on my side, for something was very wrong.
Hungry for blood, I attempted to throw confusion in the enemy's lines
and checked the startup data.
I wondered… could it be… but the changes were made in the application,
shouldn't it betray me then?
Change the startup data to match exactly to that created in the
application and test.
Success, I'd a beachhead on the enemy's front.
But it was still too early to get cocky; I tried to change the startup
data again, and checked what this might cause.
Treason! Mayhem! The exception only struck if I tried to insert the
most important items.
But how could the enemy reveal that? The only difference I could see
that some of the items were selected (they were created and then
selected on previous, more successful campaigns).
Impossible, for such a small change to create such drastic
measurements! Yet I'd seen it with my own eyes.
Item. Checked = Group. Selected;
This was the traitor.
If Group. Selected was true, then I was for an unpleasant surprise
trying to insert.
But why should it make any difference?
I tested, commenting this line and sending scouts ahead. They returned
with glowing eyes, talking about a rich land, if only I could overcome
the treason in my own camp…
I could not get rid of the traitor; he was too dear to me, so I sent
him to the front, after the insertion occurred.
And a miracle occurred, my surprised attack was successful, and I had
scored the enemy lines in many fronts.
But there was still the matter of the traitor…
I sent him to the front with a small unit, and he excelled, and so I
slowly enlarged his command until I finally had so sent him a
lieutenant – and then disaster struck.
Again a flank attack, directly at my weak spot. And now I've located
the real tratior.
He was a small routine, meant to handle ItemCheck called from the
TreeListView, the problem with him was that he used this code:
Group add_grp = Messages.Items[e.Index].Tag as Group;
Apperantly, TreeListView (and ListView, its base) first call the
ItemCheck delegate when they get an item with Checked = true and only
afterward they add the item to their Item list.
So whenever this routine was called, it would generate an
IndexOutOfBoundException, I couldn't trace it to its real location
using StackTrace because I'm using threads to create a responsive UI.
Conclusions:
• Always have a UnhandledException and ThreadException handlers, that
could've saved me a long time, I just tested it, and it would've give
me the real stack trace of the error which would've enabled me to
solve this in a few minutes.
• I would've never caught on to this bug if I wasn't trying to
repreduce the problem and settle on the workaround.
• Debugging multi-threading code is fun as an excrise for the bored
mind.
• The only reason that I got this exception from the main thread was
that I was using Invoke to update the UI, otherwise, I was into more
trouble.
• That was a lovely way to spend the night, thank you very much.