Tim, > It seems like the input "int nBytes" is the problem, as it is passed to > VSIMalloc whicih takes a size_t type. The int type is signed and 32-bit so > it can't handle over 2 * 2^30 (2 GB). It's probably rolling over, then when > cast to size_t it is interpreted as that huge size in the OSX error > message.
I've fixed the issue per https://trac.osgeo.org/gdal/ticket/6828 > > Also, is there any plan to expose the boolean that controls whether it takes > ownership of the passed in buffer? As it is now, calling this function > requires 2x the memory because of the malloc and memcpy. Maybe the > ownership of the buffer is too tricky when dealing with multiple languages > and reference counting... Yes ownership might be complicated. In your above example, you could simplify it a lot by doing : drv = gdal.GetDriverByName("GTiff") ds = drv.Create("/vsimem/48000.tif", 48000, 48000, 1, gdal.GDT_Byte) ds = None Or if you need to create a "real" file and ingest it into memory, you can do: drv = gdal.GetDriverByName("GTiff") ds = drv.Create("48000.tif", 48000, 48000, 1, gdal.GDT_Byte) ds = None mem_f = gdal.VSIFOpenL("/vsimem/48000.tif", "wb") with open("48000.tif", "rb") as f: while True: membuf = f.read(4096) gdal.VSIFWriteL(membuf, 1, len(membuf), mem_f) if len(membuf) < 4096: break gdal.VSIFCloseL(mem_f) Even -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
