[gradsusr] memory allocation error in gxhpng / printim

[pr]

Jennifer,

Thanks for the response.

Ok, great to know that this will be fixed in the next major upgrade.

For now, I guess this can simply serve as an FYI  to others who may
experience the same issue,

or as a workaround for those who feel confident enough to modify the source
code.

 

Thanks,

Pablo

 

From: gradsusr-bounces at gradsusr.org [mailto:gradsusr-bounces at gradsusr.org]
On Behalf Of Jennifer Adams
Sent: Wednesday, January 05, 2011 1:59 PM
To: GrADS Users Forum
Subject: Re: [gradsusr] memory allocation error in gxhpng / printim

 

Hi, Pablo --

You are correct in your diagnosis, but we cannot just change the datatype of
the metafile buffer elements without breaking all the code that reads the
metafile buffer. That is something that Brian and I are not willing to do --
it makes version 2.0 backwards incompatible in an unacceptable way. Version
2.1 will have a complete overhaul of the graphics, a redesign of the
metafile buffer, and no need for the translator routines like gxeps; that is
when your shapefile with one gigantic polygon will be handled properly. 

--Jennifer

 

On Jan 5, 2011, at 3:38 PM, P. R.M. wrote:





Hi,
this is a message/question for grads developers...

A short while back I saw some messages go by regarding the mysterious
'memory allocation errors' in gxhpng when drawing large shapefiles and using
printim.
I ran into this problem yesterday when trying to draw gshhs shapefiles
(using the new, built-in 'draw shp' command).

I dug into the source code and did some debugging.
It turns out that the grads metabuffer is based on using short (16-bit)
integers.
So, regardless of the amount of memory your system has,  the maximum number
of polygon vertices that can be stored in the buffer is 32,767.

In my case, the gshhs shapefile I was trying to draw had about 40,000
vertices. 
Since this value couldnt be stored in the metabuffer, I was getting a 'junk'
negative value for the polygon vertext count, and this was causing the
memory allocation to fail.

My quick&dirty workaround was to upgrade the metabuffer's 'short ints' to
regular 'gaint' datatypes.
I guess this effectively doubles the memory usage of the metabuffer & grads
in general.
However, it solved the problem...

I didnt try converting to 'unsigned short' integers in the metabuffer
read/write routines, 
but perhaps this could be implemented instead of being forced to use long
integers?

pablo
_______________________________________________
gradsusr mailing list
gradsusr at gradsusr.org
http://gradsusr.org/mailman/listinfo/gradsusr

 

--

Jennifer M. Adams

IGES/COLA

4041 Powder Mill Road, Suite 302

Calverton, MD 20705

jma at cola.iges.org

 





 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20110105/ae0fb19a/attachment-0003.html