Opened 6 years ago
Closed 6 years ago
#7167 closed defect (invalid)
Crash when cloning a OGRSpatialReference via = operator
Reported by: | ClemensA | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | default | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: |
Description
I am developing an application using the WMTS driver in GDAL. However, opening the following subdataset causes an access violation:
GDALOpen("WMTS:https://www.basemap.at/wmts/1.0.0/WMTSCapabilities.xml,layer=geolandbasemap", GA_ReadOnly);
I attached a debugger and found that the crash occurs in the WMTS driver (wmtsdataset.cpp), where a WMTSDataset object is cloned using the `=' operator:
CPLDebug("WMTS", "Using tilematrix=%s (zoom level %d)", oTMS.aoTM[nMaxZoomLevel].osIdentifier.c_str(), nMaxZoomLevel); oTMS.aoTM.resize(1 + nMaxZoomLevel); poDS->oTMS = oTMS;
One of the members of oTMS is an OGRSpatialReference. The program crashes when it tries to clone that member. More specifically, the crash happens at OGR_SRSNode::InsertChild, during the call to CPLRealloc().
This is my stack trace:
ntdll.dll!0000000076f523f8() Unknown Non-user code. Cannot find or open the PDB file. ntdll.dll!0000000076f522d2() Unknown Non-user code. Cannot find or open the PDB file. ucrtbase.dll!000007fee4ab022d() Unknown Non-user code. Cannot find or open the PDB file. gdal202.dll!VSIRealloc(void * pData, unsigned __int64 nNewSize) Line 810 C++ Symbols loaded. gdal202.dll!CPLRealloc(void * pData, unsigned __int64 nNewSize) Line 238 C++ Symbols loaded. gdal202.dll!OGR_SRSNode::InsertChild(OGR_SRSNode * poNew, int iChild) Line 268 C++ Symbols loaded. gdal202.dll!OGR_SRSNode::AddChild(OGR_SRSNode * poNew) Line 242 C++ Symbols loaded. gdal202.dll!OGR_SRSNode::Clone() Line 383 C++ Symbols loaded. gdal202.dll!OGR_SRSNode::Clone() Line 382 C++ Symbols loaded. gdal202.dll!OGRSpatialReference::operator=(const OGRSpatialReference & oSource) Line 272 C++ Symbols loaded. [External Code] Annotated Frame > gdal202.dll!WMTSDataset::Open(GDALOpenInfo * poOpenInfo) Line 1851 C++ Symbols loaded. gdal202.dll!GDALOpenEx(const char * pszFilename, unsigned int nOpenFlags, const char * const * papszAllowedDrivers, const char * const * papszOpenOptions, const char * const * papszSiblingFiles) Line 2817 C++ Symbols loaded. gdal202.dll!GDALOpen(const char * pszFilename, GDALAccess eAccess) Line 2571 C++ Symbols loaded.
Note: You will need to provide the ssl certificate to access https websites, for example via CPLSetConfigOption("CURL_CA_BUNDLE", "path/to/cacert.pem"); You can get a certificate file here: https://curl.haxx.se/docs/caextract.html
The above crash happens on a current build of GDAL. I am developing in VS 2017, 64-bit.
I am relatively new to GDAL, so please be patient with me ;-)
Best regards,
Clemens
Change History (4)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
I suspect an issue with your build. Did you make sure to clean before rebuilding in case you changed settings, like DEBUG vs non-DEBUG build ?
comment:3 by , 6 years ago
You are right - I just did a complete rebuild of all dependencies and gdal itself, and the problem went away. Not sure what caused the problem in the first place (pretty sure I *did* clean in-between builds). In any case, thanks for your help!
If someone in the future stumbles upon a similar problem, here is the build chain that worked for me on VS 2017, 64-bit:
- Build openssl-1.1.0g - Build curl-7.57.0 with SSL support - build configuration `DLL Debug/Release - DLL OpenSSL' - you may have to change the names of openssl libraries, since they have changed from libeay.lib and ssleay32.lib to libcrypto.lib and libssl.lib - Build gdal-2.2.3 - Resolve linker errors by following the advice at: https://stackoverflow.com/questions/26024919/unresolved-external-symbol-when-compiling-gdal-1-11-0-on-windows - Link curl as dynamic library - Build in VS 2017 command line: - nmake -f makefile.vc MSVC_VER=1910 WIN64=1 DEBUG=0 devinstall - Build proj-4.9.3
comment:4 by , 6 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
You shouldn't have linker errors normally. Not sure to understand the outcome of https://stackoverflow.com/questions/26024919/unresolved-external-symbol-when-compiling-gdal-1-11-0-on-windows. But you can definitely have 'normal' builds completing. See http://build2.gisinternals.com/sdk/build-output/vc15x64-20171202-13-47-31-08-vc15x64-dev.txt for the log of gisinternals
Actually, I just checked, even the official example at http://www.gdal.org/frmt_wmts.html crashes when called in the command line:
However, the same call succeeds when using a prebuilt binary from http://www.gisinternals.com/ . Maybe there is something wrong with my GDAL build? Perhaps this issue only occurs when building GDAL in VS 2017?