public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Fabian Vogt <fabian@ritter-vogt.de>
To: newlib@sourceware.org
Subject: impure_data never reclaimed
Date: Sat, 05 Dec 2020 15:27:52 +0100	[thread overview]
Message-ID: <3052588.mabWh2cJZc@linux-e202.suse.de> (raw)

Hi,

I'm using newlib as libc on top of an OS which provides malloc and free.
Threads aren't supported, but programs can be started and stopped. The used
heap is shared between all programs, so leaked memory is lost forever. Thus
it is important that after a clean exit, every allocation was properly freed.

Currently this simple program leaks three allocations though:

#include <stdio.h>
int main()
{
    setbuf(stdout, NULL); // This would be properly freed, avoid distraction
    printf("This is 0.5 as a float: %f\n", 0.5f);
}

Those are from Balloc, which allocates a list also for later use.
FWICT, _reclaim_reent takes care of freeing the list and its contents, but:
- _reclaim_reent is never called for _impure_ptr (== &impure_data)
- _reclaim_reent does nothing if impure_ptr is passed

Is the OS glue code supposed to do something like this in _exit?

    struct _reent *global_reent = _impure_ptr;
    _impure_ptr = NULL;
    _reclaim_reent(global_reent);

With that the leaks are gone, but it seems a bit odd to me.

Thanks,
Fabian



             reply	other threads:[~2020-12-05 14:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-05 14:27 Fabian Vogt [this message]
2020-12-05 15:48 ` impure_data never reclaimed (unless you add the required cleanup code) Dave Nadler
2020-12-05 15:58   ` Fabian Vogt
2020-12-05 16:48     ` Dave Nadler

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=3052588.mabWh2cJZc@linux-e202.suse.de \
    --to=fabian@ritter-vogt.de \
    --cc=newlib@sourceware.org \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).