Crash under GDALGetProjectionRef #2744
Milestone
Comments
|
I can confirm that current HEAD + revert of e873aa2 fixes the crash. In my local environment the backtrace is not exactly the same, but it looks pretty similar. Here is it in case it helps: |
Actually PROJ would not be supposed to crash, as a NULL context should normally be interpreted as the default context, so there's an issue in it, but here it is good to see that it spots the NULL context, because using the NULL context is not thread-safe, so the issue on GDAL side must be better understood & adressed. |
rouault
added a commit
to rouault/PROJ
that referenced
this issue
Jul 4, 2020
Found when investigating OSGeo/gdal#2744 but the root cause of the GDAL issue is different.
Aparently not. I've extracted the tiff from the test file, (attached as a compressed img.zip) and gdalinfo is ok with it:
I've only tested 2 environments different environments, both Linux and both break:
|
|
and do you manage to reproduce with command line raster2pgsql ? |
That seems fine: This is the standalone SQL query that reproduces the issue: |
rouault
added a commit
to rouault/gdal
that referenced
this issue
Jul 4, 2020
Fix a bug affecting PostGIS raster (OSGeo#2744), and much likely GMT (https://lists.osgeo.org/pipermail/gdal-dev/2020-July/052381.html) If OSRCleanup() was called, deinit() was called on the current OSRPJContextHolder object, but due to OSGeo@e873aa2 that removed init(), the PROJ context was let at nullptr if OSRGetProjTLSContext() was called afterwards. This could result in a crash in PROJ due to a bug into it, for example if OGRSpatialReference::Clone() was called , or more subtely to potential thread issues if OSRCleanup() would be called in several threads using OSR API (due to the default nullptr PROJ context being used concurrently)
|
Reproduced, understood and fix submitted in #2746 |
rouault
added a commit
to OSGeo/PROJ
that referenced
this issue
Jul 4, 2020
Found when investigating OSGeo/gdal#2744 but the root cause of the GDAL issue is different.
rouault
added a commit
that referenced
this issue
Jul 4, 2020
Fix a bug affecting PostGIS raster (#2744), and much likely GMT (https://lists.osgeo.org/pipermail/gdal-dev/2020-July/052381.html) If OSRCleanup() was called, deinit() was called on the current OSRPJContextHolder object, but due to e873aa2 that removed init(), the PROJ context was let at nullptr if OSRGetProjTLSContext() was called afterwards. This could result in a crash in PROJ due to a bug into it, for example if OGRSpatialReference::Clone() was called , or more subtely to potential thread issues if OSRCleanup() would be called in several threads using OSR API (due to the default nullptr PROJ context being used concurrently)
|
The CI is happy now. Thanks a lot! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expected behavior and actual behavior.
While preparing newer Postgis test images I'm seeing a crash in its regress tests under in a call to GDALGetProjectionRef.
You can see some Travis logs under: https://travis-ci.org/github/Algunenano/postgis/builds/702420642
It crashes both with:
release/3.1branch, PROJ7.1branch. Example build with backtrace at the end.master, PROJmaster. Example build with backtrace at the end.Extract from the callstack:
Last known good
masterbuild (not super recent I know): GDAL: GDAL 3.2.0dev-60a090a-dirty, released 2020/05/08Current master build, which is crashing: GDAL: GDAL 3.2.0dev-69b0c4e-dirty, released 2020/06/25
I've managed to reproduce the issue locally so I'm trying to bisect the issue to pinpoint the specific commit, but it might take some time (there are ~500 commits between the 2 of them, and building gdal is not particularly fast :D). Any pointers as to what to build or test might save me tons of time.
Steps to reproduce the problem.
Under Postgis build tree already built
./raster/test/regressrun:Operating system
Linux. The travis build are using
debian:unstable-slimand my local version is running under ArchLinux.GDAL version and provenance
Both 3.1 and master seem to be affected.
Not seeing the issue with GDAL 3.0 + PROJ master (7.1.0.r13.g42b9c119a) or PROJ 6.3.1 (tag).
The text was updated successfully, but these errors were encountered: