Dave Peterson, chief marketing officer of Coverity, describes the nature of the defects as follows: "resource leaks, memory corruptions, null pointer dereferences." The scan found 359 defects, 88 of which were "high risk." High risk defects are bugs that "in theory, that could have security implications." That is, they could lead to trouble but are not yet targeted by the troublemakers.
The defects are common programming errors. Operating systems build objects from class libraries, modules of code to be used for a particular individual need, then discarded. If the object remains in random access memory, along with a build-up of many other used objects, it will eventually choke the limited memory of a mobile device. That's one example of a resource leak -- a memory leak. It poses a risk of causing a device crash once memory is filled to the brim.
A C language null pointer dereferences causes a mobile device's software to look for a value in memory that is no longer there. The pointer returns a null value and the program stalls. The programmer should have been more fastidious in going back over all his previous steps to eliminate any pointers no longer needed. It's painstaking work; sometimes a pointer is overlooked.
Are these named bugs security risks? "We don't know what effects they may have or not have," said Peterson.
So 88 defects in about 720,000 lines of code need to be attended to in a particular HTC release of the Android "Froyo" kernel. A scan of other manufacturer's source code, say Motorola's or Nokia's, might yield different results. HTC has been aggressively adopting the Android system and modifying it through contributions from many different vendors. It's also been operating in a more open manner that makes it subject to easy scrutiny.
In the short run, that makes HTC subject to charges that it's producing buggy, inferior code for its phones. In the long run, if the identified defects get corrected, it will show that it clears up bugs quickly and forges ahead with rapid development. Such a stance will pay off for HTC and Android. Meanwhile, we have Coverity watching and publicizing results from its automated scans.
Android developers need to take a lesson from their Linux kernel elders. They've driven their bug rate down to .127 per 1,000 lines of code or one-eighth the average. Android developers need to do likewise. To do so will take more time and developer investment than aggressive Android development has allowed so far. But the adjustment should come sooner rather than later.
