This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix memory leak in printf_positional
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Paul Pluzhnikov <ppluzhnikov at google dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, Paul Eggert <eggert at cs dot ucla dot edu>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Sun, 30 Aug 2015 06:29:57 +0200
- Subject: Re: [PATCH] Fix memory leak in printf_positional
- Authentication-results: sourceware.org; auth=none
- References: <1440571295-20230-1-git-send-email-eggert at cs dot ucla dot edu> <alpine dot DEB dot 2 dot 10 dot 1508260930500 dot 26898 at digraph dot polyomino dot org dot uk> <55DFB7C7 dot 50307 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1508281350520 dot 5939 at digraph dot polyomino dot org dot uk> <55E06924 dot 2000209 at redhat dot com> <CALoOobMkGafD9zvq9g13TM8_Nd+HmC58_8gMGTQhdefXpko3CA at mail dot gmail dot com>
On Sat, Aug 29, 2015 at 11:38:13AM -0700, Paul Pluzhnikov wrote:
> On Fri, Aug 28, 2015 at 6:59 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> > On 08/28/2015 09:55 AM, Joseph Myers wrote:
> >> On Thu, 27 Aug 2015, Carlos O'Donell wrote:
> >>
> >>> I agree, but I don't think anyone should spend more than an hour trying
> >>> to find such a test case. The static analysis tools can show you a failure,
> >>
> >> I really don't think this case should take that long to find how to
> >> trigger the leak.
>
> It doesn't take very long: all I needed is a printf invocation with >=
> 65536 / 3 / sizeof(void*) arguments.
>
> Writing such invocation by hand is of course toublesome, plumbing
> Makefile to generate it for me, and figuring out why it doesn't work
> is what takes time :-(
>
> In addition, there is a GCC regression: compiling a printf call with
> 2800 arguments takes 4.8.4-2ubuntu1~14.04 0.06s without optimization,
> 0.86s with -O2. Same numbers for current GCC trunk (@r227321): 0.06s
> and 4m46s. This is on a very recent and fast PC. I expect there could
> be PCs in current use where the time will be 3x longer.
>
> Are we willing to tolerate such long compile times for a test case?
> If so, I'll send a combined patch.
>
There is also problem what this would catch, as in future a problem
could be with 65536 arguments or other magical constant this isn't that
much useful.