tech@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: Abhinav Upadhyay <er.abhinav.upadhyay@gmail.com>
Cc: tech@mdocml.bsd.lv
Subject: Re: Possible Memory leak in mdoc_validate.c?
Date: Thu, 7 Apr 2016 20:10:21 +0200	[thread overview]
Message-ID: <20160407181021.GA15064@athene.usta.de> (raw)
In-Reply-To: <CAHwRYJkz-fNjM=xBFXhhduSyMXX3G5MNWEuM8kJYpADu3FmHGA@mail.gmail.com>

Hi Abhinav,

Thanks for still caring about mandoc.

Abhinav Upadhyay wrote on Thu, Apr 07, 2016 at 11:08:42PM +0530:

> The function post_os in mdoc_validate.c has a static char *defbuf,
> which doesn't seem to be free'd after allocation. Shouldn't it be
> free'd and set to NULL if it was allocated?

No, that would defeat the purpose.  The whole point of the exercise
is to keep the string around, such that it does not need to be
constructed again.

> On Linux, valgrind was reporting a warning that the memory allocated
> here was still reachable, the following change got rid of that warning
> for me.

Such tools are not perfect, and this is a false positive.
Use them as tools, don't blindly break the code by making them
shut up in some random way.

This is not a memory leak.  Suppose a program, for example
makewhatis(8), is running over a large number of mdoc(7) manuals.
For each correctly formatted manual, this function post_os() will
be called once.  If the .Os macro has an argument or mandoc(1) was
called with -Ios, that argument will be used and the code you propose
to change will not be reached.

If -Ios is not used, then for the first manual where the .Os macro
does not have an argument, uname(3) will be called and the result
will be formatted and saved in defbuf.  A copy will be saved in
that manual's mdoc structure.  That copy will be free(3)d when done
with that particular manual.

For any other manuals having .Os macros without arguments during that
run of the program, the string in defbuf will be copied again, such
that uname(3) doesn't need to be called again.

The earliest time when defbuf could possibly be freed is after
completing processing of the last manual.  But at that point, that's
pointless because the program will exit anyway.  Consider defbuf
as a constant string of unspecified length.

Yours,
  Ingo


> Index: dist/mdoc_validate.c
> ===================================================================
> RCS file: /cvsroot/src/external/bsd/mdocml/dist/mdoc_validate.c,v
> retrieving revision 1.9
> diff -u -r1.9 mdoc_validate.c
> --- dist/mdoc_validate.c    7 Jan 2016 20:05:41 -0000    1.9
> +++ dist/mdoc_validate.c    3 Apr 2016 11:51:09 -0000
> @@ -2289,6 +2289,10 @@
>                  utsname.sysname, utsname.release);
>      }
>      mdoc->meta.os = mandoc_strdup(defbuf);
> +    if (NULL != defbuf) {
> +        free(defbuf);
> +        defbuf = NULL;
> +    }
>  #endif /*!OSNAME*/
> 
>  out:
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

  reply	other threads:[~2016-04-07 18:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-07 17:38 Abhinav Upadhyay
2016-04-07 18:10 ` Ingo Schwarze [this message]
2016-04-07 19:21   ` Abhinav Upadhyay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160407181021.GA15064@athene.usta.de \
    --to=schwarze@usta.de \
    --cc=er.abhinav.upadhyay@gmail.com \
    --cc=tech@mdocml.bsd.lv \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).