On Tuesday 04 September 2001 02:01, Tobias Rundstr?m wrote:
> On mЕn, sep 03, 2001 at 11:21:45 -0600, Sasha Pachev wrote:
> > mysql_real_query() can appear to a memory leak checker to leak because it
> > uses alloc_root() - our own internal memory allocation pool code. The
> > important thing is:
> >
> > * if you call mysql_real_query() several times, the amount of the "leak"
> > should not be growing outrageously, and should stay at around the total
> > length of the field names + a little overhead
>
> It is growing to a great size after a while, I have a presistiant connection
> to the mysql server and are running mysql_real_query from time to time. do
> I have to run mysql_close() sometimes just to free up some memory? after
> stressing my program with a lot of mysql querys I get this BIU (blocks in
> use) report. (for you not familiar to dbx this is just a way to show what
> memory that is allocated)
>
> Found 390 blocks totaling 3183960 bytes (54.59% of total; avg block size
> 8164)
> At time of each allocation, the call stack was:
> [1] my_malloc() at 0xe610adb0
> [2] alloc_root() at 0xe610de64
> [3] unpack_fields() at 0xe6106334
> [4] mysql_read_query_result() at 0xe61078c4
> [5] mysql_real_query() at 0xe6108624
> [6] our_mysql_query() at line 212 in "mysql.c"
>
> So is could there be some other explanation? is this memory not freed if I
> miss doing a free_result or something.
You need to call mysql_free_result() after calling mysql_store_result(). If
you are already doing that, isolate the problem to a small sample code
segiment that compiles and run, and we will take a look at it.
--
MySQL Development Team
For technical support contracts, visit https://order.mysql.com/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sasha Pachev <sasha@stripped>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA
<___/
