Yes, but (that I know) we don't get long stack traces in VS.
Exception thrown at 0x00007FFF88F87788 in osmcoastline.exe: Microsoft C++
exception: gdalcpp::gdal_error at memory location 0x000000CD6E33E090.
Unhandled exception at 0x00007FFF88F87788 in osmcoastline.exe: Microsoft
C++ exception: gdalcpp::gdal_error at memory location 0x000000CD6E33E090.
The program '[37264] osmcoastline.exe' has exited with code 0 (0x0).
I can see why it crashes but why it happens. To start with the code is
completely mysterious for me
class Driver : private init_library {
gdal_driver_type* m_driver;
public:
Driver(const std::string& driver_name) :
init_library(),
#if GDAL_VERSION_MAJOR >= 2
m_driver(GetGDALDriverManager()->GetDriverByName(driver_name.c_str())) {
#else
m_driver(OGRSFDriverRegistrar::GetRegistrar()->GetDriverByName(driver_name.c_str()))
{
#endif
if (!m_driver) {
throw gdal_error(std::string("unknown driver: '") + driver_name + "'",
OGRERR_NONE, driver_name);
}
}
m_driver is defined as a function, which is than tested to be NULL (and it
is) and a crash follows.
A stack trace would give others a chance to possibly spot what the crash
is.
On Wed, Sep 14, 2016 at 11:31 AM, Joaquim Luis <jl...@ualg.pt> wrote:
OK, clean & rebuilt (as I (thought) did before) and I can see the
SQLite driver now.
However, the osmcoastline still crashes. Unfortunately, it's too damn
C++ for me to debugg.
Le mercredi 14 septembre 2016 19:43:22, Joaquim Luis a écrit :
Sorry, my bad. When I thought I was using gisinternals I was actually
using my build. Gisinternals does show the SQLite driver.
But one of my points still holds. If the Walker shows me that
sqlite3.dll
is a dependency than why the SQLite driver is not available?
You mentionned that you "(re)build" GDAL with sqlite, so I assume you
added it
after a first build. So I suspect that some files didn't get
recompiled. The
safest way if not already done is to clean and rebuild.
Otherwise, mostly for a quick check, you may just 'touch'
ogr/ogrsf_frmts/generic/ogrregisterall.cpp but you'll probably miss a
few files
that will benefit from sqlite being now available. So the clean &
rebuild path
is the safest ultimately.
Hmm, several (weird) things.
1. I'm using GnuWin ports for unix commands. And:
- this works
gdalinfo --formats | sort
- this not (output is empty)
ogfinfo --formats | sort
Same thing for 'grep'
2. To check I'm using gisinternals and same thing as my build.
ogrinfo --formats shows no SQLite driver
3. The program I'm trying to build/run crashes at this line
https://github.com/osmcode/osmcoastline/blob/master/include/gdalcpp.hp
p#L132 (no idea why it crashes) apparently because it doesn't
find the
SQLite driver (driver_name == 'SQLite')
ogrinfo --formats | grep -i lite
SQLite -vector- (rw+v): SQLite / Spatialite
On Wed, Sep 14, 2016 at 9:32 AM, Joaquim Luis <jl...@ualg.pt> wrote:
Sorry Even that you are bombed with so many questions.
I have (re)build GDAL with sqlite and can confirm with The
(Dependency) Walker that the sqlite3.dll is a gdal.dll dependency.
However,
gdalinfo --formats
...
Rasterlite -raster- (rws): Rasterlite
SAFE -raster- (rov): Sentinel-1 SAR SAFE Product
SAR_CEOS -raster- (rov): CEOS SAR Image
SDTS -raster- (rov): SDTS Raster
SENTINEL2 -raster- (rovs): Sentinel 2
SGI -raster- (rw+): SGI Image File Format 1.0
SRTMHGT -raster- (rwv): SRTMHGT File Format
TIL -raster- (rov): EarthWatch .TIL
...
does not show the SQLite driver and indeed a program that I'm
building
that needs to link with GDAL (osmcoastline) crashes when it doesn't
find >>>that driver.
?
Joaquim
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
----
http://schwehr.org
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
----
http://schwehr.org
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
