[splint-discuss] memory leak detection
evans at cs.virginia.edu
Sun Nov 2 09:59:05 EST 2003
On Sun, 2 Nov 2003, Roland Illig wrote:
> On Sat, Nov 01, 2003 at 09:58:46PM -0500, David Evans wrote:
> > Splint's analysis isn't sophisticated enough to figure this out. If you
> > do,
> > free(this_string);
> > this_string = NULL;
> > it will prevent the warning.
> I just checked the manual, and in clause 5.2.1#5 it states that
> "After the release obligation is transferred, the original reference
> is a dead pointer and the storage it points to may not be used."
> 5.2.1#3 says:
> * assign it to an external reference declared with an only annotation
> According to these statements, the following program should be ok,
> shouldn't it?
The warning isn't complaining directly about a memory leak here --- its
complaining about the state of this_string being different along two
paths. Along the true path, it does
last_string = this_string;
which makes this_string dependent (but live). On the false branch, it
does free(this_string) which makes this_string dead. As the warning
The state of a variable is different depending on which branch is taken.
This means no annotation can sensibly be applied to the storage. (Use
-branchstate to inhibit warning)
Splint's analysis avoids path explosion by merging states after multi-path
statements, but in this case the states are inconsistent so a warning is
produced. If splint had more path sensitive analyses, or dealt with local
variable assignments in a better way, it would be able to avoid producing
the spurious warning here.
More information about the splint-discuss