From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gclgu-libc-help@m.gmane-mx.org>
Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214])
 by sourceware.org (Postfix) with ESMTPS id 8CF3A384B072
 for <libc-help@sourceware.org>; Wed, 17 Mar 2021 17:30:26 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8CF3A384B072
Received: from list by ciao.gmane.io with local (Exim 4.92)
 (envelope-from <gclgu-libc-help@m.gmane-mx.org>) id 1lMa00-0009UY-Ly
 for libc-help@sourceware.org; Wed, 17 Mar 2021 18:30:24 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: libc-help@sourceware.org
From: Ian Pilcher <arequipeno@gmail.com>
Subject: Bug or not? printf allocates buffer & never frees it
Date: Wed, 17 Mar 2021 12:30:19 -0500
Message-ID: <s2tebb$135j$1@ciao.gmane.io>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.0
X-Mozilla-News-Host: news://news.gmane.org:119
Content-Language: en-US
X-Spam-Status: No, score=3.5 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,
 FORGED_GMAIL_RCVD, FORGED_MUA_MOZILLA, FREEMAIL_FORGED_FROMDOMAIN,
 FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_ASCII_DIVIDERS,
 KAM_DMARC_STATUS, NML_ADSP_CUSTOM_MED, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=no autolearn_force=no version=3.4.2
X-Spam-Level: ***
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: libc-help@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Libc-help mailing list <libc-help.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-help>,
 <mailto:libc-help-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-help/>
List-Help: <mailto:libc-help-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-help>,
 <mailto:libc-help-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Mar 2021 17:30:29 -0000

Fedora 33 with glibc-2.32-4.fc33.x86_64.

Simple reproducer:

  #include <mcheck.h>
  #include <stdio.h>

  int main(void)
  {
	mtrace();
	printf("%d\n", 0);
	muntrace();
	return 0;
  }

Running with MALLOC_TRACE set shows:

  Memory not freed:
  -----------------
             Address     Size     Caller
  0x0000000000e1d690    0x400  at 0x7f19511d2934

The trace file shows that the memory was allocated by
_IO_file_doallocate:

  = Start
  @ /lib64/libc.so.6:(_IO_file_doallocate+0x94)[0x7f19511d2934] + 
0xe1d690 0x400
  = End

And gdb shows that _IO_file_doallocate is called from printf:

  #0  0x00007ffff7e578a0 in _IO_file_doallocate () from /lib64/libc.so.6
  #1  0x00007ffff7e662f0 in _IO_doallocbuf () from /lib64/libc.so.6
  #2  0x00007ffff7e65488 in __GI__IO_file_overflow () from /lib64/libc.so.6
  #3  0x00007ffff7e64536 in __GI__IO_file_xsputn () from /lib64/libc.so.6
  #4  0x00007ffff7e4f269 in __vfprintf_internal () from /lib64/libc.so.6
  #5  0x00007ffff7e3b2af in printf () from /lib64/libc.so.6
  #6  0x0000000000401163 in main () at leak.c:11

Multiple calls to printf don't leak additional memory, so this isn't
really a problem (other than the time wasted by folks hunting memory
leaks).

Is this considered a bug?

-- 
========================================================================
                  In Soviet Russia, Google searches you!
========================================================================