It happened again. For what seems like the 100th time, someone reports to me that they are seeing a number of false positive reports on the resource leak checker. For those not familiar with a resource leak, take a look at a previous post. Although resource leaks apply across most languages, the place where this...

It happened again. For what seems like the 100th time, someone reports to me that they are seeing a number of false positive reports on the resource leak checker. For those not familiar with a resource leak, take a look at a previous post. Although resource leaks apply across most languages, the place where this question keeps coming up seems to always be in Java or C# code. My last query came from Java code, so we will use that as an example. Here was a report where the FileInputSteam is not closed on exit.

Do you see this issue? Clearly, they close the FileInputStream in the finally block. The problem is that you can still throw an exception when you try to create a FileOutputStream. The simple fix is to encompass the FileInputStream and FileOutputStream in the try/catch blocks.

Static analysis tools are great for finding bugs like this resource leak. In this case, the report that a FileInputStream is not closed on exit wasn’t enough information to debug this. This brings us to a very important discussion with static analysis tools–trace.

Gone are the days where a static analysis tool reports a bug at line X with no context. Today you get detailed traces. The trace contains conditions and assignments to give you clues about why the tool is identifying a bug. In this example below, identifying the “source” and “sink” of any defect will help you trace through the start/end of the control flow.

More importantly in the case of Java, here we have a clear understanding where exceptions are thrown. This would have helped tremendously for the example above.

Detailed traces are very important and can do many things for individual checkers. So whatever you do, don’t just look at the bug description, pay attention to the trace!

About the Author:
Alen Zukich

Hello, I'm Klocwork's Director of Product Management responsible for the company's product direction. I’m an Electrical Engineering graduate and CSPO. I’ve been with Klocwork for over a decade now including the time before we spun out. My passion is in the development tools space, so expect content related to software development.

Our Social Networks

A while ago I talked about memory overflows. Now in this latest installment, as we look at more interesting bugs, I’ve come across a new example. Here is a situation described by a customer as “stack smashing”, which occurs when you copy a string of unknown length into a fixed buffer size. Just like the ...

A few years back a customer said they had all kinds of trouble with bugs corrupting their stack. Even though they asked if source code analysis tools could help find stack corruption, once we got an example, we found that they were really looking for was memory overflows. So what on earth is a memory ...

It happened again. For what seems like the 100th time, someone reports to me that they are seeing a number of false positive reports on the resource leak checker. For those not familiar with a resource leak, take a look at a previous post. Although resource leaks apply across most languages, the place where this ...

As a product manager, the only backlog I typically care about is my product backlog. Do I have the right stories in there? Do the stories have enough detail? Are they properly prioritized? You know, that kind of stuff. Today, however, I’m going to write about a very different backlog, that is the static analysis defect ...