Re: maximing/resizing multiple x11: change of palette

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

I see something I consider a memory leak in the gnuplot_x11 palette. 
 I'm on the downhill side of revamping the MakePalette routine and will 
fix this, so I don't know if it is worth fixing in CVS or 4.0 errata. 
 If you are curious what the problem is, read on...

=========

Considering the case of supplying a gradient or user-defined 
(user-defined is implemented as a special type of gradient) the routine

static void
scan_palette_from_buf( plot_struct *plot )
{
    t_sm_palette tpal;

will scan a user-defined palette from the pipe.  In the case of  "case 
SMPAL_COLOR_MODE_GRADIENT: {" there is a malloc:

    tpal.gradient = (gradient_struct*)
      malloc( tpal.gradient_num * sizeof(gradient_struct) );

but this memory is never freed anywhere and you see above that "tpal" is 
local, hence this information is discarded.

*However*, this memory can't be freed here.  The current CVS version 
insided PaletteMake() of gplt_x11.c keeps a record of the most recent 
palette sent across the pipe.  And inside of there is:

    case SMPAL_COLOR_MODE_GRADIENT:
      sm_palette.gradient_num = tpal->gradient_num;
      sm_palette.gradient = tpal->gradient;

Notice that this doesn't malloc() any memory.  It just keeps a record of 
the memory that was malloc'd in the scan_palette_from_buf() routine 
above.  So, if one were to free the memory in scan_palette_from_buf(), 
this sm_palette.gradient would be a bogus pointer and later when a 
"palettes_differ()" were called, it would crash from accessing invalid 
memory.

The bottom line is that nowhere is memory for an outdated gradient 
palette discarded.  It could be fixed with a few extra mallocs and 
frees, but I don't know if it is worth it seeing as I'm almost done with 
a re-vamping of the palette stuff.

I've verified this leak by running the imagegp.m script in Octave.  The 
script uses a gnuplot user-defined palette.  If I keep plotting the same 
image, the memory consumption for gnuplot_x11 just keeps growing.

Dan