3 ms·

Some bugs are just really hard to find, diagnose, verify, fix and then verify the fix. At a previous employer, I was responsible for a very long running servic

Some bugs are just really hard to find, diagnose, verify, fix and then verify the fix. At a previous employer, I was responsible for a very long running service that usually had an uptime of about 9-10 months. At one point we noticed we had a memory leak that was directly related to the number of requests the service processed. The kicker: it leaked less than a single byte per request in an x64 C++ service. It took us about a year to find the cause. Turned out to be a bug in an in house logging lib that failed to create a rolled log file in case of a filesystem full or disk usage quota exceeded condition, which we rarely ever encountered in development because we wiped logs every week in dev, but on a more relaxed schedule in prod.

olliej 7y ago
Agreed, like I said it will be interesting see what the final patch set will be. Diagnosing some bugs can take a huge amount of time, work, and luck (I had a bug one time where the repro steps required a specific google reader account and a stapler resting on the space bar for an hour or so). But for a bug that has a trivial test case, especially in the context of parsing/validating bugs generally, isolating the bug should not be hugely challenging (a few days). Much more likely in my experience is that the nature of the specific flaw indicates that there is a pattern in your code base that is potentially unsafe - at that point you want to fix all instances of the pattern, because when you release the patch you’re documenting the flawed pattern.