This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: glibc 2.26 memory leak with MySQL?
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Michael Brunnbauer <brunni at netestate dot de>, libc-help at sourceware dot org, DJ Delorie <dj at redhat dot com>
- Date: Mon, 14 Aug 2017 08:59:49 -0400
- Subject: Re: glibc 2.26 memory leak with MySQL?
- Authentication-results: sourceware.org; auth=none
- References: <20170812141938.GA26871@netestate.de>
On 08/12/2017 10:19 AM, Michael Brunnbauer wrote:
> Have there been any changes that can explain this, e.g. the per-thread cache
> for malloc?
Michael,
The other thing we can do is run your workload with a tracing glibc.
The tracing glibc captures a workload of all of your malloc API family calls
and then we can use that reproduce a simulation of your applicatoin.
We use a simulator to run the workload again and again with slightly different
parameters to see what's going on.
Adding DJ to the TO: since he's the workload/simulator's primary author.
Depending on the length of the run, and the time it takes to capture the OOM,
the binary workload trace file can get quite large.
DJ,
Do we have a rebased tracer against glibc 2.26?
Cheers,
Carlos.