Today I was digging around an audio bug where an earlier fix for one model of hardware was breaking things for a slightly different model.
The fix that had introduced the bug had modified generic code for a subset of hardware and in doing so broke the code for all the other cases. The fix should have been a quirk for a specific subset of hardware. This made me wonder how many bugs are like this - somebody fixes a bug which then causes regressions for almost identical classes of hardware. It would be interesting to know how many regressions occur like this.
The problem is that when dealing low level tinkering, one can only really test one's own hardware and produce a fix for that; making sure it's not causing regressions is hard as one usually does not have all the other hardware to test against. Also, for this particular bug it's not totally clear in hindsight that the original fix was flawed; eye-balling the code may have picked up the bug earlier - but this can be incredibly difficult to do and get right 100% of the time.
After digging down and identifying *where* the code was wrong was the hard part.
As it was, diff'ing the buggy code with some upstream quickly showed me a fix and backporting this was a no-brainer.
No comments:
Post a Comment