[rrd-developers] RFC: [PATCH] Portability by avoiding PATH_MAX

Svante Signell svante.signell at gmail.com
Thu May 8 07:18:36 CEST 2014

On Thu, 2014-05-08 at 02:05 +0100, Steven Hartland wrote:
> ----- Original Message ----- 
> From: "Svante Signell" <svante.signell at gmail.com>
> To: "rrdtool dev list" <rrd-developers at lists.oetiker.ch>
> Sent: Tuesday, April 29, 2014 1:35 PM
> Subject: [rrd-developers] RFC: [PATCH] Portability by avoiding PATH_MAX
> > Hello,
> > 
> > Here are updated patches for rrdtool/rrd_client.c and
> > rrdtool/rrd_daemon.c. We had some discussions in August last year. I
> > created a branch and the diffs are against latest git. I've run the
> > code, especially rrd_daemon with valgrind under Linux, but need some
> > help to check that also rrd_client works OK (maybe rrd_daemon too). Can
> > you help me with test cases to run the execute the code modified paths.
> > I know one application using rrdtool, lm-sensors (build-dependency on
> > librrd2-dev), but am not sure my computers have the sensors to be a good
> > test case.
> > 
> > Note that the modified functions get_path() and get_abs_path() are
> > static, so they don't change the API.
> This looks like it would cause a lot of unnessary malloc free surely
> the correct fix for this is to fix the OS config to define PATH_MAX.
> Quick look at the patches also show its quite broken:-
> +  tmp = malloc(len);
> +  snprintf(tmp, len, "%s/%s", config_base_dir, *filename);
>    *filename = tmp;
> +  free(tmp);
> So you just malloced some memory, assigned the pointer to it then freed
> the memory, so your now going to get a use after free and BOOM!

This is of course wrong, thanks! You see the reason for having tests
together with valgrind to find out these problems. Did you find more?

More information about the rrd-developers mailing list