setting layerObj.metadata is unsafe and cause segfault or access violation

[szekerest]

With the current implementation setting layerObj.metadata with a newly created
metadata object may cause cause segfault or access violation.

Creating a new object (HashTableObj in this case) sets the internal swigCMemOwn
flag to true indicating that the referenced unmanaged memory should be destroyed
on finalization. Calling setmetadata will copy the the memory of the unmanaged
hashTableObj structure but the internal items will not be copied.
Therefore the items of the hashtable of the layer will be destroyed when the
finalization of the created HashTableObj occurs.

Resolution: layerObj.metadata should be read only. One should get the reference
of the hashtable of the layer and add the items as needed.

[szekerest]

After looking into the code i have found several other places this problem
persists. By setting these properties a raw copy of the object is done however
the  subsequent referenced objects will not be copied.

classObj.label  (labelObj)
classObj.metadata  (hashTableObj)
classObj.layer  (layerObj)
fontSetObj.fonts  (hashTableObj)
imageObj.format  (outputFormatObj)
labelPathObj.path (lineObj)
legendObj.label  (labelObj)
legendObj.map  (mapObj)
mapObj.symbolset (symbolSetObj)
mapObj.fontset  (fontSetObj)
mapObj.labelcache  (labelCacheObj)
mapObj.reference  (referenceMapObj)
mapObj.scalebar  (scalebarObj)
mapObj.legend  (legendObj)
mapObj.querymap (queryMapObj)
mapObj.web  (webObj)
mapObj.configoptions  (hashTableObj)
webObj.map  (mapObj)
webObj.metadata  (hashTableObj)

One should avoid to set these parameters until it is fixed.

Marking this problem as critical.

Tamas

[tomkralidis]

Tamas,

Trying this in perl mapscript returns no error:

my $layer = new mapscript::layerObj() || die "Can't create layerObj: $!\n";
$layer->{metadata}->set("wms_name", "gfoo");
print $layer->{metadata}->get("wms_name") ."\n";

Is this what you mean?

[tomkralidis]

Trying this in perl gives me error:

[devgeo:/home/tkralidi/dd]$ perl dd.pl
Can't locate auto/mapscript/layerObj/set.al in @INC (@INC 
contains: /usr/lib/per
l5/site_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5/i386-
l
inux-thread-multi /usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-
multi /usr/li
b/perl5/site_perl/5.8.3/i386-linux-thread-
multi /usr/lib/perl5/site_perl/5.8.6 /
usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl/5.8.4 /usr/lib/perl5/sit
e
_perl/5.8.3 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.6/i386-
linux
-thread-multi /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-
multi /usr/lib/
perl5/vendor_perl/5.8.4/i386-linux-thread-
multi /usr/lib/perl5/vendor_perl/5.8.3
/i386-linux-thread-
multi /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_
perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3 /u
s
r/lib/perl5/vendor_perl /usr/lib/perl5/5.8.6/i386-linux-thread-
multi /usr/lib/pe
rl5/5.8.6 .) at dd.pl line 11

[szekerest]

drawmap.cs

[szekerest]

Added a simple example to reproduce the problem for C#. The simplest way to test
it is to replace the drawmap.cs with this code and use

nmake -f makefile.vc
nmake -f makefile.vc test

on windows for example.   

[szekerest]

drawmap.java

[szekerest]

Added the corresponding java example.

Upon the developer's agreement i've committed the necessary changes and closing
this bug.