Opened 17 years ago

Closed 17 years ago

Last modified 16 years ago

#2351 closed defect (fixed)

Producing very large maps fails without appropriate errors

Reported by: warmerdam Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL Support Version: 4.10
Severity: normal Keywords: raster
Cc: dmorissette, flavio, benft

Description

Rendering this map:

NAME "Üp 1:10'000"
SIZE 9000 9000
STATUS ON
EXTENT 628750 242000 637500 248000
UNITS METERS
IMAGECOLOR 255 255 255
IMAGETYPE JPEG

OUTPUTFORMAT
  NAME jpeg
  DRIVER "GD/JPEG"
  MIMETYPE "image/jpeg"
  IMAGEMODE RGB
  EXTENSION "jpg"
  FORMATOPTION "QUALITY=100"
END

#=============================================================================
# Swiss projection
#=============================================================================

PROJECTION
  "init=epsg:21781"
END

# ---------------------------------------------------------------------------- 
# UP
# ---------------------------------------------------------------------------- 

LAYER
	NAME "UP 1:10000"
	TYPE RASTER
	STATUS ON
	#MAXSCALE 10000
	DATA 'test.tif'
	PROCESSING "RESAMPLE=AVERAGE"
	PROJECTION
	 "init=epsg:21781"
	END
END
END # Ende MapFile

for file:

Driver: GTiff/GeoTIFF
Files: test.tif
Size is 35000, 24000
Coordinate System is `'
Origin = (628749.875000000000000,248000.125000000000000)
Pixel Size = (0.250000000000000,-0.250000000000000)
Metadata:
  TIFFTAG_SOFTWARE=IrfanView
  TIFFTAG_XRESOLUTION=1016
  TIFFTAG_YRESOLUTION=1016
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
Image Structure Metadata:
  COMPRESSION=PACKBITS
Corner Coordinates:
Upper Left  (  628749.875,  248000.125) 
Lower Left  (  628749.875,  242000.125) 
Upper Right (  637499.875,  248000.125) 
Lower Right (  637499.875,  242000.125) 
Center      (  633124.875,  245000.125) 
Band 1 Block=35000x1 Type=Byte, ColorInterp=Palette
  Metadata:
    NBITS=1
  Color Table (RGB with 2 entries)
    0: 255,255,255,255
    1: 0,0,0,255

fails on win32 system, when using the command shp2img on the map. The output map is 9K x 9K and it appears between the main gd image and the memory allocated in the raster resampling code the 32bit address space is exhausted. This might be ok, except that reasonable errors are not returned. Just a report that the layer failed to render.

It appears the raster rendering code does not report out of memory errors sensible, and in fact does not even check malloc() failures in some places it ought to. Problem experienced in 4.10 and 5.

Change History (5)

comment:1 by warmerdam, 17 years ago

In the process of investigating this report (using "limit vmemorysize 510megabytes on linux) I found some problems with GDAL's out-of-memory handling addressed at:

http://trac.osgeo.org/gdal/ticket/1914

comment:2 by warmerdam, 17 years ago

Fixed failure to allocate gdImage in mapgd.c (resulting in crash in some sitations) in trunk as r6941). Fixed missing memory allocation checks, and added nice error reporting for out of memory in mapdrawgdal.c in trunk as r6942.

Ported into 5.0 branch as r6943.

comment:3 by warmerdam, 17 years ago

Resolution: fixed
Status: newclosed

err, make that r6944 for the 5.0 changeset.

comment:4 by benft, 16 years ago

I think I may be victimized by this: the map image I'm attempting is 4204x2687

and I get these errors messages (which are bogus) when calling $image = $oMap->drawQuery() :

PHP Warning: Error: msDrawRaster(): Unrecognized or unsupported image format PHP Warning: Error: drawEPP(): EPPL7 support is not available. Is this fix released? Would it be possible to patch it in without rebuilding mapserver (which I'm not able to do)? We have 4.10.0

Thanks! Ben Thompson

comment:5 by warmerdam, 16 years ago

Cc: dmorissette flavio benft added; dmorissette flavio removed

Ben,

This doesn't sound like the same error to me. And there is no way to backport these fixes into 4.10 without someone rebuilding from source.

Note: See TracTickets for help on using tickets.