A lot of times, reducing a bug report to the simplest possible example isn't quite enough. The thing that really makes the difference between fixing a bug quickly or not is giving information about what works and what doesn't work. Here's a great example that I culled down from a recent bug report.
Dim m As MemoryBlock = NewMemoryBlock( 128*4 )
Dim p As Ptr = m
Dim i As Integer = 264
p.Single(i) = p.Single(i) + 2.0
MsgBox Str( p.Single( i ) )
This code would display the value "0" instead of "2", and then crash. However, if you replace every instance of "i" with 264, then the crash would go away. Like this:
Dim m As MemoryBlock = NewMemoryBlock( 128*4 )
Dim p As Ptr = m
Dim i As Integer = 264
p.Single(264) = p.Single(264) + 2.0
MsgBox Str( p.Single( 264 ) )
That is what I mean by "differential." In one case, it crashes, and in the other case it works.
By doing this differential testing, I saved myself numerous hours of headache. Just that one simple piece of information made the difference between a 15-minute fix and a 4 hour fix. The reason will not be appearant externally, but internally it was immediate. The x86 backend treats constant offsets different from variable offsets with regards to peek and poke. It literally narrowed the issue down from about 2000 lines of code to about 6 lines.
So what's the moral of the story? When testing, it's great to narrow the project down (the original project was only about twice as large as the snippet I've provided, so it was done pretty well) along with any information about what causes the crash to go away! The more information in your bug reports the better, even if it doesn't seem too important to you. I'd much rather see a report with way too much detail than one with way too little -- in the former case there's a much better chance I'll fix the bug quickly. In the latter case, it's sometimes likely the report won't even be reproducible, depending on just how little information is available.
Ya, I should've caught that earlier (I reported a similar constant vs variable issue with the broken NOT operator on PPC). Another user did make a note that constants worked shortly after the report was created however.
Anyway, thanks for the quick fix - I'm glad you didn't spend 4 hours on it, but I spent at least that long debugging and cutting the project down to those 7 lines of code (on my own time) so we'll call it even ;)
Heh, sorry to call you out on that report. I actually thought it was very well reduced when I saw it come in. That's why I decided to work on it in my spare time, truth be told. :-) I just figured it'd make an excellent example of how knowing when the bug works and fails makes the fix even easier. Thanks for the excellent report!