Memory corruption in ST_BandPath

[strk]

The ST_BandPath code contains memory error resulting in random memory being dumped for offline bands, see #2771.

Indeed the code seems to be destroying the memory containing the string before copying it to final value for return: ​https://github.com/postgis/postgis/blob/2.1.3/raster/rt_pg/rt_pg.c#L2619-L2628

[strk]

2.0 is also affected: ​https://github.com/postgis/postgis/blob/2.0.6/raster/rt_pg/rt_pg.c#L2387-L2395

I'm taking a look at fixing it in 2.0

[strk]

Forget it, I'm getting coredumps in testapi ! … filing another ticket about that (could be GDAL version related)

[Bborie Park]

Still worth fixing.

What stack are you using for 2.0's testapi?

[strk]

My patch for 2.0 is this one:

diff --git a/raster/rt_pg/rt_pg.c b/raster/rt_pg/rt_pg.c
index 2ced796..e020e0b 100644
--- a/raster/rt_pg/rt_pg.c
+++ b/raster/rt_pg/rt_pg.c
@@ -2385,10 +2385,10 @@ Datum RASTER_getBandPath(PG_FUNCTION_ARGS)
     }
 
     bandpath = rt_band_get_ext_path(band);
-               rt_band_destroy(band);
-    rt_raster_destroy(raster);
     if ( ! bandpath )
     {
+        rt_band_destroy(band);
+        rt_raster_destroy(raster);
         PG_RETURN_NULL();
     }
 
@@ -2398,6 +2398,9 @@ Datum RASTER_getBandPath(PG_FUNCTION_ARGS)
 
     strcpy((char *) VARDATA(result), bandpath);
 
+    rt_band_destroy(band);
+    rt_raster_destroy(raster);
+
     PG_RETURN_TEXT_P(result);
 }

For the memory corruption I filed #2773

[Bborie Park]

I'd have suggested moving the strcpy up instead…

[strk]

your call, I can't test 2.0 and I'm getting ready for the weekend anyway, so it's all yours in all branches. Have fun !

[Bborie Park]

I used your patch. Fixed in trunk as of r12631. Fixed in 2.1 as of r12632. Fixed in 2.0 as of r12633