svn commit: r240527 - head/bin/df

[Erik Cederstrand]

Den 16/09/2012 kl. 18.05 skrev Eitan Adler <eadler at FreeBSD.org>:

> On 16 September 2012 10:24, Tijl Coosemans <tijl at coosemans.org> wrote:
>> On 16-09-2012 01:27, Eitan Adler wrote:
>>> On 15 September 2012 17:20, Bruce Cran <bruce at cran.org.uk> wrote:
>>>> On 15/09/2012 21:57, Tijl Coosemans wrote:
>>>>> 
>>>>> Freeing memory right before exiting is a waste of time. The tool shouldn't
>>>>> complain about it.
>>> 
>>> Perhaps, but tools do. This has already been brought up on cfe-dev.
>>> 
>>>> "/Stop wasting time and just exit already/." -
>>>> http://blogs.msdn.com/b/oldnewthing/archive/2012/01/05/10253268.aspx
>>> 
>>> I read this blog post when it came out. :)
>> 
>> In this case the free is actually wrong, because the pointer can point
>> to memory allocated by getmntinfo(3) and that manpage says an application
>> cannot free it.
> 
> Ah, I missed that.  I wish this point was brought up earlier.  I'll
> revert the commit

I was the one who filed the PR (http://www.freebsd.org/cgi/query-pr.cgi?pr=171634). I'm embarrassed to have caused a wrong commit.

The big picture is I'm looking through the Clang Analyzer scans at http://scan.freebsd.your.org/freebsd-head trying to find false positives to report back to LLVM. Their PR originated in this warning: http://scan.freebsd.your.org/freebsd-head/bin.df/2012-09-12-amd64/report-WwB2qk.html#EndPath The scan has 326 warnings about possible memory leaks in world, so I'd really like to do something here, be it either via bug report with LLVM or FreeBSD or to annotate the code to say it's okay to break the rules.

There response from LLVM (disregarding that mntbuf can't be freed) is either that: 1) if main() is redefined as a macro, it's still a leak, and 2) they can skip the warning only if it's feasible to reason that prtstat() doesn't allocate memory.

I noticed that the sentence "The memory allocated by getmntinfo() cannot be free(3)'d by the application." in the getmntinfo(3) manage is in the bugs section. Does this mean it's something that should be fixed in FreeBSD eventually?

Erik