Patrick Lau <patro02@stripped> writes:
> But my mysqld is built with the config option --without-query-cache...
>
> Is it really the query cache or can it also be our own stuff allocated
> with my_malloc?
Sorry I meant _key cache_ of course. As seen in this call on the stack trace:
>>> ==13045== by 0x820BC12: _ZL16create_key_cachePKcj
> (set_var.cc:3586)
Generally, for each leak (or non-leak in the case of "still reachable"),
Valgrind will show the stack trace of where the memory was allocated, which
should help you determine if and how it is related to your code.
Also, I would suggest running your query several times, and only look at the
Valgrind reports from VALGRIND_DO_LEAK_CHECK starting after a few queries have
been run, to get one-time initialisations like this one to settle down.
- Kristian.
| Thread |
|---|
| • Valgrind, MySQL - a single query mem check | Patrick Lau | 16 Mar |
| • Re: Valgrind, MySQL - a single query mem check | Kristian Nielsen | 16 Mar |
| • RE: Valgrind, MySQL - a single query mem check | Ivan Novick | 16 Mar |
| • Re: Valgrind, MySQL - a single query mem check | Patrick Lau | 16 Mar |
| • Re: Valgrind, MySQL - a single query mem check | Kristian Nielsen | 16 Mar |
| • Re: Valgrind, MySQL - a single query mem check | Patrick Lau | 17 Mar |
| • Re: Valgrind, MySQL - a single query mem check | Jocelyn Fournier | 17 Mar |
| • Re: Valgrind, MySQL - a single query mem check | Kristian Nielsen | 17 Mar |
| • Re: Valgrind, MySQL - a single query mem check | Stewart Smith | 17 Mar |
| • Re: Valgrind, MySQL - a single query mem check | Patrick Lau | 17 Mar |