gdalnumeric.SaveArray possible python referencing problem

[gillian.walter@…]

gdalnumeric.SaveArray seems to do something strange to the referencing of the
array being saved in the current CVS version of GDAL (using Fedora core 3
linux).  To reproduce, launch a python shell and enter:

import gdalnumeric
import Numeric
arr=Numeric.array([[5.3,2,1],[3,2,1]])
gdalnumeric.SaveArray(arr,'/home/test.tif')
arr # to try to print the array

This causes a segmentation fault.  I was also able to reproduce the problem with
the python/gdal in FWTools 1.0.0a7 for linux.

[gillian.walter@…]

*** Bug 1134 has been marked as a duplicate of this bug. ***

[warmerdam]

The problem seems to have been that the bands for the GDAL dataset associated
with the array were MEMRasterBand's which derive from GDALPamRasterBand.
When the CreateCopy() method calls CloneInfo() this results in a call to 
GetDefaultRAT() on the MEMRasterBand's which happens to call PamInitialize()
on the bands.  But PamInitialize() on the bands calls PamInitialize() on the
dataset without regard to whether the dataset is actually a GDALPamDataset
or not (an unsafe C style cast is used).  It turns out that the MEMDataset
does *not* derive from GDALPamDataset so this resulted in subtle corruption 
to MEMDataset as the MOFlags were set in GDALPamDataset::PamInitialize(). 

It happens that this hits the psArray pointer and means that the array is 
not properly dereferenced in ~MEMDataset().  In at least some cases this 
ended up causing a crash.  

I have committed changes so that the GDALPamDataset and GDALPamRasterBand
keep track that they are PAM objects using the new GMO_PAM_CLASS flag
in the GDALMajorObject MO flags.  This seems to correct the problem. 

Whew, this was a tricky one to dig out, but could cause a number of 
other subtle effects.