Version 5.6.1 does not work for non-referenced raster images

[janh]

The attached unreferenced raster and map do not work for me with MapServer 5.6.1: the application hangs without any error. In 4.10.5 there are no problems

This could be a problem with my new 64bits server: I had lots of very nasty problems since I upgraded, e.g. ​http://trac.osgeo.org/mapserver/ticket/3241#comment:20.

The attached map is the "Warmonderdam"-polder near Leiden in 1850, nowadays known as Warmerdam (​http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=warmonderdam&sll=37.230328,-95.712891&sspn=48.695847,78.310547&ie=UTF8&hq=warmonderdam&hnear=&radius=15000&ll=52.214155,4.503107&spn=0.009282,0.019119&t=h&z=16)

[warmerdam]

Problem confirmed on linux with mapserver trunk. It seems to be hanging waiting to acquire a mutex.

digging further.

[warmerdam]

I have confirmed it was a locking problem similar to one we have run into before. msAcquireLock() will not let a single thread multiple acquire a lock. In this situation mapresample.c code calls msGetGDALGeoTransform() which tries to acquire the GDAL lock even though the higher level context already held it.

The fix is to release the lock before calling msGetGDALGeoTransform(), which I have done in trunk (r9945) and 5.6 branch (r9946).

The problem only hits in a few cases, georeferencing-less rasters appears to be one of those.

I believe this fix is just in time to make the 5.6.2 release.

[janh]

No, sorry, I didn't look at the output map. Mapserv produces a regular map in version 4, hangs with version 5, and produces the map on its head in svn. The svn-PHP-Mapscript module produces nasty errors in my regular applications ("internal server error" or even "proxy error"), which I don't know how to debug further. The attached simple php-script, based on the existing map and jpeg, shows the map on its head too.

[warmerdam]

Ok, I found that the GetExtent implementation that was introduced for 5.6 (or possibly 5.4?) was not flipping ungeoreferenced rasters the same way that msGetGDALGeoTransform() was. It also wasn't checking for success in GDALGetGeotransform(). I made adjustments there to give appropriate behavior.

I also found there were still problems with trying to multiply acquire TLOCK_GDAL. So I have reworked things so that msGetGDALGeoTransform() now assumes the caller holds the lock, and it only releases the lock if calling the OWS GetExtent function.

Lastly, I try to avoid calling OWS GetExtent unless I know there is OWS Metadata to avoid going down to the layer GetExtent which does an expensive GDALOpen just toget the extent.

I have applied the changes in trunk (r10000 - woot!) and in 5.6 branch (r10001). Any testing that could be done - especially from the 5.6 branch - would be appreciated.

[janh]

Almost there. CGI works, but PHP-Mapscript gives a nasty "Internal Server Error", when I add a setSize() command. See attached php2 file

[warmerdam]

Jan,

I don't have php on my system and it is not exactly handy to install for me. I tried the following python script with no problems:

import mapscript
map = mapscript.mapObj('warmerdam.map')
map.setSize(400,400)
img = map.draw()
img.save('out.png')
print 'done'

I wonder if the problem is something with your build or perhaps a side effect of something else that was changing? Do you have any authoritative reason to believe it relates to this ticket? If not, I'd suggest you refile it as a distinct ticket.

[janh]

The problem is only in trunk (downloaded 2010-03-26). Branch 5.6 (downloaded 2010-03-28) seems to be completely OK now, so this ticket can be closed. Please update the download-version.

The PHP-code in trunk seems to be completely rewritten from 5.6.3 (it's even in a different subdirectory, php instead of php3). The program segfaults in map.c, line 1173, function PHP_METHOD(mapObj,setSize) when it tries to create a new mapObj:

php_map = (php_map_object *) zend_object_store_get_object(zobj TSRMLS_CC);

Should I make a ticket for a bug in trunk, and if so, to whom should it be adressed?

[warmerdam]

Jan,

This is a php mapscript rewrite issue on 64bit systems. I'll file a separate ticket on it and cc: you. In brief, I believe there are problems with the current php mapscript bindings for anything passing integers on 64bit systems.