From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward106p.mail.yandex.net (forward106p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:109]) by sourceware.org (Postfix) with ESMTPS id A7659384C005 for ; Wed, 17 Mar 2021 19:23:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A7659384C005 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=yandex.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hi-angel@yandex.ru Received: from myt6-ca5f80bdfc44.qloud-c.yandex.net (myt6-ca5f80bdfc44.qloud-c.yandex.net [IPv6:2a02:6b8:c12:2ca8:0:640:ca5f:80bd]) by forward106p.mail.yandex.net (Yandex) with ESMTP id C4AD01C83F5A; Wed, 17 Mar 2021 22:23:14 +0300 (MSK) Received: from myt6-9bdf92ffd111.qloud-c.yandex.net (myt6-9bdf92ffd111.qloud-c.yandex.net [2a02:6b8:c12:468a:0:640:9bdf:92ff]) by myt6-ca5f80bdfc44.qloud-c.yandex.net (mxback/Yandex) with ESMTP id NSrHvQ6myy-NEq0u0Gf; Wed, 17 Mar 2021 22:23:14 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1616008994; bh=IW41li7glwk0FX+X/8cqZpYUEaltMapNr9koN1/JEWU=; h=In-Reply-To:To:From:Subject:Message-ID:References:Date; b=LK1Tzp9idC9OwcCwq4io/+F8Xp9bZ8G9uHbfhSj2PlcBmp1/9Wji80hGbudmumDoO tsj8AD8ZuPzMnnjU3bctj8rSZOBeCNiRZM7+v/IdOhbSUjGLA2ROlj1mGqsurDHuAK 8zgAqeIh90bhS0WSCGsiqFXASqCLKde2D2parckQ= Authentication-Results: myt6-ca5f80bdfc44.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Received: by myt6-9bdf92ffd111.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id LA79VXKN2L-NEJ4kLwt; Wed, 17 Mar 2021 22:23:14 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Message-ID: <1c2230b2d1f2ffef4ac8041188373ebbdc6064cc.camel@yandex.ru> Subject: Re: Bug or not? printf allocates buffer & never frees it From: Konstantin Kharlamov To: Ian Pilcher , libc-help@sourceware.org Date: Wed, 17 Mar 2021 22:23:14 +0300 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 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 List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 19:23:19 -0000 On Wed, 2021-03-17 at 12:30 -0500, Ian Pilcher via Libc-help wrote: > Fedora 33 with glibc-2.32-4.fc33.x86_64. > > Simple reproducer: > >   #include >   #include > >   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? > Hi! I'm not very acknowledged with the output, am I right that printf calls "deallocate", however the actual memory is still being held and not returned to the kernel? If yes, then you're likely stumbled upon this bug https://sourceware.org/bugzilla/show_bug.cgi?id=27103 See also this gigantic thread https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45200