Re: [gdal-dev] Allocate large memory space with CPLMalloc(). Bug or not?
Thanks for reply, I'll try VSIMalloc().
But can you explain the goal of check if( long(nSize) < 0 ) {...} in
CPLMalloc()? Cast size_t to long leads to implicit result.
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Allocate-large-memory-space-with-CPLMalloc-Bug-or-not-tp5227443p5227453.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Allocate large memory space with CPLMalloc(). Bug or not?
Thanks for reply, I'll try VSIMalloc().
But can you explain the goal of check *if( long(nSize) < 0 ) {...}* in
CPLMalloc()? Cast size_t to long leads to implicit result.
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Allocate-large-memory-space-with-CPLMalloc-Bug-or-not-tp5227443p5227452.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Allocate large memory space with CPLMalloc(). Bug or not?
Le jeudi 01 octobre 2015 21:18:33, fazotron a écrit :
> Hello!
>
> Take a look on the following code:
>
> *...
> size_t w = 1, h = 5000, d = 150;
> size_t sz = w * h * d * sizeof(float); // ~27.94 Gb
>
> float *volume = (float*)CPLMalloc(sz);
> ...*
>
> In this case GDAL throws error in runtime: "ERROR 1: CPLMalloc(-664771072):
> Silly size requested."
> But I think that it's not silly, because such amount of free RAM is
> available on my system. For example I can successfully allocate it calling
> standart malloc().
>
> I have opened CPLMalloc() source code and seen the following lines:
>
> *void *CPLMalloc( size_t nSize )
> ...
> if( long(nSize) < 0 )
> {
> CPLError( CE_Failure, CPLE_AppDefined,
> "CPLMalloc(%ld): Silly size requested.\n",
> (long) nSize );
> return NULL;
> }
> ...*
>
> In my case long( size_t nSize ) returns negative value and it leads to
> error.
> As far as I understand converting one integer type to another smaller
> integer type (e.g. long long/size_t to long) is implementation-defined, so
> it's not safe to use CPLMalloc() with 64-bit integers.
CPLMalloc() is not meant at being used for big allocations since it aborts if
the allocation fails. Use VSIMalloc() instead that will return NULL in case of
failed alloc
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/Allocate-large-memory-space-with-CPLMa
> lloc-Bug-or-not-tp5227443.html Sent from the GDAL - Dev mailing list
> archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Allocate large memory space with CPLMalloc(). Bug or not?
On Thu, Oct 1, 2015 at 1:18 PM, fazotron wrote:
>
> Hello!
>
> Take a look on the following code:
>
> *...
> size_t w = 1, h = 5000, d = 150;
> size_t sz = w * h * d * sizeof(float); // ~27.94 Gb
>
> float *volume = (float*)CPLMalloc(sz);
> ...*
>
> In this case GDAL throws error in runtime: "ERROR 1: CPLMalloc(-664771072):
> Silly size requested."
> But I think that it's not silly, because such amount of free RAM is
> available on my system. For example I can successfully allocate it calling
> standart malloc().
>
> I have opened CPLMalloc() source code and seen the following lines:
>
> *void *CPLMalloc( size_t nSize )
> ...
> if( long(nSize) < 0 )
> {
> CPLError( CE_Failure, CPLE_AppDefined,
> "CPLMalloc(%ld): Silly size requested.\n",
> (long) nSize );
> return NULL;
> }
> ...*
>
> In my case long( size_t nSize ) returns negative value and it leads to
> error.
> As far as I understand converting one integer type to another smaller
> integer type (e.g. long long/size_t to long) is implementation-defined, so
> it's not safe to use CPLMalloc() with 64-bit integers.
>
According to the documentation, CPLMalloc is a convenience for
'smaller' allocations where the caller is 'unwilling to test for out
of memory conditions':
/**
* Safe version of malloc().
*
* This function is like the C library malloc(), but raises a CE_Fatal
* error with CPLError() if it fails to allocate the desired memory. It
* should be used for small memory allocations that are unlikely to fail
* and for which the application is unwilling to test for out of memory
* conditions. It uses VSIMalloc() to get the memory, so any hooking of
* VSIMalloc() will apply to CPLMalloc() as well. CPLFree() or VSIFree()
* can be used free memory allocated by CPLMalloc().
*
* @param nSize size (in bytes) of memory block to allocate.
* @return pointer to newly allocated memory, only NULL if nSize is zero.
*/
Use the VSIMalloc*() family, it is just a wrapper for malloc, but
checks for overflow in VSIMalloc2(), VSIMalloc3().
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/Allocate-large-memory-space-with-CPLMalloc-Bug-or-not-tp5227443.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Kyle
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Allocate large memory space with CPLMalloc(). Bug or not?
Hello!
Take a look on the following code:
*...
size_t w = 1, h = 5000, d = 150;
size_t sz = w * h * d * sizeof(float); // ~27.94 Gb
float *volume = (float*)CPLMalloc(sz);
...*
In this case GDAL throws error in runtime: "ERROR 1: CPLMalloc(-664771072):
Silly size requested."
But I think that it's not silly, because such amount of free RAM is
available on my system. For example I can successfully allocate it calling
standart malloc().
I have opened CPLMalloc() source code and seen the following lines:
*void *CPLMalloc( size_t nSize )
...
if( long(nSize) < 0 )
{
CPLError( CE_Failure, CPLE_AppDefined,
"CPLMalloc(%ld): Silly size requested.\n",
(long) nSize );
return NULL;
}
...*
In my case long( size_t nSize ) returns negative value and it leads to
error.
As far as I understand converting one integer type to another smaller
integer type (e.g. long long/size_t to long) is implementation-defined, so
it's not safe to use CPLMalloc() with 64-bit integers.
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Allocate-large-memory-space-with-CPLMalloc-Bug-or-not-tp5227443.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] (no subject)
Hi Konstantin, Can you explain your case. For example for WMS driver (TMS) GDAL_HTTP_PROXY config option works for me. Best regards, Dmitry 01.10.2015 14:39, Константин Лапин пишет: Hi, CPLSetConfigOption( "GDAL_HTTP_PROXY",proxy.toLocal8Bit().data()); CPLSetConfigOption( "GDAL_PROXY_AUTH", "NTLM" ); CPLSetConfigOption( "GDAL_HTTP_PROXYUSERPWD", " : " ); how to make "bypass proxi for local adresses" ? С уважением, Константин Лапин lk...@mail.ru ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] (no subject)
Hi, CPLSetConfigOption( "GDAL_HTTP_PROXY",proxy.toLocal8Bit().data()); CPLSetConfigOption( "GDAL_PROXY_AUTH", "NTLM" ); CPLSetConfigOption( "GDAL_HTTP_PROXYUSERPWD", " : " ); how to make "bypass proxi for local adresses" ? С уважением, Константин Лапин lk...@mail.ru___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt RFC 59.1: GDAL/OGR utilities as a library
Le mardi 29 septembre 2015 12:45:43, Even Rouault a écrit : > Hi, > > Since no remarks have been done on the latest proposal, I move to adopt RFC > 59.1: GDAL/OGR utilities as a library > > https://trac.osgeo.org/gdal/wiki/rfc59.1_utilities_as_a_library > > Starting with my +1, Hi, This motion has passed with +1 from DanielM and myself. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp fails to warp for this GeoPDF
Le 01/10/2015 10:42, Even Rouault a écrit : > > I don't think so. Looks like an issue with your GDAL and/or proj.4 install. > The proj.4 string for EPSG:3857 reported above is wrong. It should be (as > reported by gdalsrsinfo "EPSG:3857"): > > +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 > +k=1.0 +units=m +nadgrids=@null +wktext +no_defs > It fails also here. I think that the problem comes from the projection parameters stored in the PDF file (the scale factor is null). ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp fails to warp for this GeoPDF
Le jeudi 01 octobre 2015 09:31:33, Gane R a écrit : > Hi, > > https://drive.google.com/file/d/0B4shTM1bPS5TZ3psWTFpU1ZuV2c/view?usp=shari > ng > > gdalwarp -t_srs EPSG:3857 "file04.pdf" "file04.tif" > > ERROR 6: Failed to initialize PROJ.4 with `+proj=merc +lon_0=0 +k=0 +x_0=0 > +y_0= > 0 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs '. > k <= 0 > > Is this due to PDF driver ?, I don't think so. Looks like an issue with your GDAL and/or proj.4 install. The proj.4 string for EPSG:3857 reported above is wrong. It should be (as reported by gdalsrsinfo "EPSG:3857"): +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdalwarp fails to warp for this GeoPDF
Hi, https://drive.google.com/file/d/0B4shTM1bPS5TZ3psWTFpU1ZuV2c/view?usp=sharing gdalwarp -t_srs EPSG:3857 "file04.pdf" "file04.tif" ERROR 6: Failed to initialize PROJ.4 with `+proj=merc +lon_0=0 +k=0 +x_0=0 +y_0= 0 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs '. k <= 0 Is this due to PDF driver ?, gdalinfo of this file follows gdalinfo file04.pdf Projection: PROJCS["unnamed",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84 ",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORI TY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree", 0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]],PROJECTIO N["Mercator_1SP"],PARAMETER["central_meridian",0],PARAMETER["scale_factor",0],PA RAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["Meter",1]] RasterCount: 3 RasterSize (5388,3341) Using driver Geospatial PDF Metadata: 0: AUTHOR=anonymous 1: CREATION_DATE=D:20150626141600Z 2: NEATLINE=POLYGON ((-9778005.7471570373 5257640.588139087,-9778432.250753 6598 5258664.8154589375,-9776778.2288263608 5259347.8824177133,-9776351.72522973 83 5258323.6550978627,-9778005.7471570373 5257640.588139087)) 3: PRODUCER= Corner Coordinates: Upper Left (-9778858.754336, 5259689.04274448) Lower Left (-9778432.25075366, 5258664.81545894) Upper Right (-9777204.73240246, 5260372.10970584) Lower Right (-9776778.22882012, 5259347.88242029) Center (-9777818.55540679, 5259518.61586393) Coordinate System is: PROJCS["unnamed", GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9108"]], AUTHORITY["EPSG","4326"]], PROJECTION["Mercator_1SP"], PARAMETER["central_meridian",0], PARAMETER["scale_factor",0], PARAMETER["false_easting",0], PARAMETER["false_northing",0], UNIT["Meter",1]] Band 1 : DataType: Byte ColorInterpretation: Red Description: Size (5388,3341) BlockSize (5388,1) Offset: 0 Scale: 1 Band 2 : DataType: Byte ColorInterpretation: Green Description: Size (5388,3341) BlockSize (5388,1) Offset: 0 Scale: 1 Band 3 : DataType: Byte ColorInterpretation: Blue Description: Size (5388,3341) BlockSize (5388,1) Offset: 0 Scale: 1 Gane ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
