Software tool finds bugs in real time

It is not a new problem, of course, and ways of working collaboratively are being developed and improved all the time. But while developing code in tandem with your colleagues is a good thing, it is not such a good thing if you, or your colleagues, are writing bad code – introducing bugs into the project. Back at the turn of the Millennium, the erstwhile giant of the telecoms world Nortel, was starting to look at ways of solving the problem. It was using a LINT checker to find simple faults, like incorrectly named variables. It is a tool still in wide use today and does a good job for simple fault finding. One way to find defects is to run dynamic analysis on the code, but that is downstream and a large code base takes a long time to test. It then takes a long time to find out where the defect occurred and why. "But this is a bit after the event," said Philip O'Hara, "after the horse has bolted. They started to look at static analysis and developed this tool that became Klocwork. What it does is to look at the potential pathways in the code to work out possible defects. It will find things that are really difficult to find, like memory leaks, buffer overflows, potential invalidated user inputs – things that could never have been found – and uses what is now termed as a data flow engine." That tool become a company of the same name that spun out of Nortel in 2001. O'Hara is director for EMEA for Klocwork, which was itself bought by Rogue Wave at the end of 2013 to complement its range of productivity tools for developers. In its early days, Klocwork was capable of serious defect detection, but it was still a downstream process. Code would be typed, tests run, bugs found and then it would be returned to the developer. "While that is better than dynamic testing, the useability wasn't quite as good as LINT, because LINT would sit on the developer's desktop and fix the little problems as you went along," said O'Hara. "What we did in about 2008 was to finally crack how to put Klocwork on the developer's desktop. Now what you can have a team of developers all writing their own code and they can write it in the knowledge that, as they write, we will find all these serious defects. "It's a client/server architecture. It's usability is such that you will find defects as you type – it is almost like a spell checker. It is sometimes difficult to appreciate that we are going in and finding really serious defects rather than just simple structural checks. We have now got the best of both worlds: we have the serious defect engine, but we have also the usability in that it sits on the developer's desk and that means they always send in clean code." Nobody else, claims O'Hara, can combine the serious defect detection with the ability to do it virtually in real-time on the desktop. "There are tools that will find the serious problems, but they have to have the whole program passed to them. There are also programs that work on the desktop, but only find simple structural faults." Klocwork essentially adds a couple of windows to the usual operator environment. These windows highlight defects as the developer types and points out how the error could be reached. "We don't do anything that would put the developer off. We just want them to work in a standard environment in a standard way and just highlight issues they might be introducing into the code," commented O'Hara. In the embedded space, there are four languages used in around 90% of projects – C, C++, C# and Java – and the Klocwork package can be used with all four. It automatically identifies which language is in use, which can be useful for developers using several codes on their desktop. Included in the list of more difficult defects to find are buffer overflows and validated user inputs, but something that is creating a lot of attention is the ability to find memory leaks. The server side of the client/server architecture ensures errors that relate to the developer's own code are not only highlighted, but also potential defects that could affect the wider project. Klocwork is not, however, designed to ensure that 100% working code will emerge from the developer's desktop. Steve Howard, head of partner support Europe, explained: "There are two reasons for that. One is that we are not saying the Klocwork is exhaustive. There is no way that we can do an exhaustive search of every single component in the code; it wouldn't be practical on larger code bases to ever be able to do that. So we have to use clever algorithms to look at more of the boundary conditions for each different type of defects and to try to speed detection. Essentially, it works like a chess playing game, where breaks down the paths it needs to look at based on heuristics – rules about what is likely to render a problem. We have some very efficient algorithms that will find 95% of the defects as quickly as possible, rather than 100% of the defects in an exhaustive search. In other words, saving as much time as is sensibly possible." The second reason is that Klocwork only looks at coding issues; it cannot guarantee that the code will then fulfil its ultimate function – that will require a further functional or design verification test. Howard commented: "All we are trying to do is make sure that the code itself does not look like it's going to do anything unexpected." Beyond the coding rules imposed inherently by using the four languages, Klocwork can be customised. Further rules can be added if a company wants to maintain a certain coding style or, more frequently, to meet certain standards. For example, MISRA (Motor Industry Software Reliability Association) rules can be imported to ensure developers are creating compliant code. Howard concluded: "There was a study done at Cambridge University a few years back that said 50% of the developer's time is spent on debug issues. Imagine half your time potentially being wasted! The more that we can find almost instantaneously, before you have wasted any time checking code in, code checking and changing designs later on, is really quite valuable."