[gdal-dev] Segfault in gdalrasterize

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] Segfault in gdalrasterize

Ari Jolma-2
We're seeing transient segfaults in gvBurnScanline with a huge in-memory
raster created by rasterio.

The raster size is (67264, 51776).

The segfaults happen in cloud servers, not in laptops or local virtual
machines.

Debugging is hard because rasterio installs its own libgdal but with gdb
I see with bt

#0  __memset_avx2_unaligned_erms () at
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:245
#1  0x00007ffff127646f in gvBurnScanline(void*, int, int, int, double) ()
    from ../rasterio/.libs/libgdal-c9384152.so.20.5.0

Any ideas?

Thanks,

Ari


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in gdalrasterize

Sean Gillies-3
Hi Ari,

The Linux rasterio wheels I've been putting on PyPI include libraries built for compatibility with old versions of Linux, as old as CentOS 5. If there are any differences between the OS in your cloud and what you have on your local machines, you may experience some differences. If you can, it could be worth building Rasterio from source for your deployments, which would mean installing the build prerequisites (Numpy, Cython, GDAL) and running `pip install --no-binary rasterio rasterio`.

I wonder if you're more memory contrained in the cloud than you are on your own computer and if this is part of the trouble.

On Tue, Mar 26, 2019 at 9:50 AM Ari Jolma <[hidden email]> wrote:
We're seeing transient segfaults in gvBurnScanline with a huge in-memory
raster created by rasterio.

The raster size is (67264, 51776).

The segfaults happen in cloud servers, not in laptops or local virtual
machines.

Debugging is hard because rasterio installs its own libgdal but with gdb
I see with bt

#0  __memset_avx2_unaligned_erms () at
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:245
#1  0x00007ffff127646f in gvBurnScanline(void*, int, int, int, double) ()
    from ../rasterio/.libs/libgdal-c9384152.so.20.5.0

Any ideas?

Thanks,

Ari


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
Sean Gillies

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in gdalrasterize

Even Rouault-2
In reply to this post by Ari Jolma-2
On mardi 26 mars 2019 17:50:19 CET Ari Jolma wrote:

> We're seeing transient segfaults in gvBurnScanline with a huge in-memory
> raster created by rasterio.
>
> The raster size is (67264, 51776).
>
> The segfaults happen in cloud servers, not in laptops or local virtual
> machines.
>
> Debugging is hard because rasterio installs its own libgdal but with gdb
> I see with bt
>
> #0  __memset_avx2_unaligned_erms () at
> ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:245
> #1  0x00007ffff127646f in gvBurnScanline(void*, int, int, int, double) ()
>     from ../rasterio/.libs/libgdal-c9384152.so.20.5.0

First, which GDAL version ?? :-)

>
> Any ideas?

Yes, GDAL 2.4.1 NEWS contains:

 * rasterize: fix crash when working buffer is larger than 2GB (#1338)

And the stacktrace you show reminds me a lot of the one there was for that
issue. The working buffer size is GDAL cache max dependent, which is itself
RAM dependent, hence why the bug happens on some machines and not other ones.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in gdalrasterize

Ari Jolma-2
Thanks Even,

Ari

Even Rouault kirjoitti 26.3.2019 klo 20.39:

> On mardi 26 mars 2019 17:50:19 CET Ari Jolma wrote:
>> We're seeing transient segfaults in gvBurnScanline with a huge in-memory
>> raster created by rasterio.
>>
>> The raster size is (67264, 51776).
>>
>> The segfaults happen in cloud servers, not in laptops or local virtual
>> machines.
>>
>> Debugging is hard because rasterio installs its own libgdal but with gdb
>> I see with bt
>>
>> #0  __memset_avx2_unaligned_erms () at
>> ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:245
>> #1  0x00007ffff127646f in gvBurnScanline(void*, int, int, int, double) ()
>>      from ../rasterio/.libs/libgdal-c9384152.so.20.5.0
> First, which GDAL version ?? :-)
>
>> Any ideas?
> Yes, GDAL 2.4.1 NEWS contains:
>
>   * rasterize: fix crash when working buffer is larger than 2GB (#1338)
>
> And the stacktrace you show reminds me a lot of the one there was for that
> issue. The working buffer size is GDAL cache max dependent, which is itself
> RAM dependent, hence why the bug happens on some machines and not other ones.
>
> Even
>
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segfault in gdalrasterize

Ari Jolma-2
In reply to this post by Even Rouault-2
with 2.4.1 the segfault comes from gvBurnPoint, so that may need similar
fix than gvBurnScanline

Ari


Even Rouault kirjoitti 26.3.2019 klo 20.39:

> On mardi 26 mars 2019 17:50:19 CET Ari Jolma wrote:
>> We're seeing transient segfaults in gvBurnScanline with a huge in-memory
>> raster created by rasterio.
>>
>> The raster size is (67264, 51776).
>>
>> The segfaults happen in cloud servers, not in laptops or local virtual
>> machines.
>>
>> Debugging is hard because rasterio installs its own libgdal but with gdb
>> I see with bt
>>
>> #0  __memset_avx2_unaligned_erms () at
>> ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:245
>> #1  0x00007ffff127646f in gvBurnScanline(void*, int, int, int, double) ()
>>      from ../rasterio/.libs/libgdal-c9384152.so.20.5.0
> First, which GDAL version ?? :-)
>
>> Any ideas?
> Yes, GDAL 2.4.1 NEWS contains:
>
>   * rasterize: fix crash when working buffer is larger than 2GB (#1338)
>
> And the stacktrace you show reminds me a lot of the one there was for that
> issue. The working buffer size is GDAL cache max dependent, which is itself
> RAM dependent, hence why the bug happens on some machines and not other ones.
>
> Even
>
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev