Re: memory leak?

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:

> I ran with that construct for a few hours.  I'm still seeing memory very 
> slowly increasing.

I may have by chance found at least one source of a memory leak without even going to valgrind yet.

Here is a function in set.c:

/* default settings for palette */
void
reset_palette()
{
    if (!enable_reset_palette) return;
    sm_palette.colorMode = SMPAL_COLOR_MODE_RGB;
    sm_palette.formulaR = 7; sm_palette.formulaG = 5;
    sm_palette.formulaB = 15;
    sm_palette.positive = SMPAL_POSITIVE;
    sm_palette.ps_allcF = 0;
    sm_palette.use_maxcolors = 0;
    sm_palette.gradient_num = 0;
    sm_palette.gradient = NULL;
    sm_palette.cmodel = C_MODEL_RGB;
    sm_palette.gamma = 1.5;
    pm3d_last_set_palette_mode = SMPAL_COLOR_MODE_NONE;
}

Notice that sm_palette.gradient is simply set to NULL.  But that variable is a memory pointer assigned as

    if (sm_palette.gradient) {
	free( sm_palette.gradient );
    }
    sm_palette.gradient = (gradient_struct*)
      gp_alloc( actual_size*sizeof(gradient_struct), "pm3d gradient" );

So, there needs to be a "free()" as part of that reset_palette() routine just as with the above hunk of code.  Palettes can be big, so that could easily chew up a lot of memory for some applications.

I'd also make the argument that the routines

set_palette_defined()
set_palette_file()
set_palette_function()
check_palette_grayscale()
reset_palette()

really don't need to be inside set.c and should go inside either color.c or getcolor.c.  That would help get rid of the use of a global structure variable sm_palette.

Some improvement in organization would also be pointer-based routines like compare_palette(), copy_palette(), destroy_palette() which partially exist already.  Rather than have sm_palette, maybe that would work better as a pointer.  What is nice about that is its more suitable for object-orientation as proposed by Hans if ever gnuplot moves to keeping track of multiple plot contents (rather than just the current).

Dan