FWIW, my reply with an attached image is waiting for approval.
I haven't done serious Windows coding since the NT days, but I found
this. Sounds like this will do it and then you can load the dump in
visual >studio and get the stack track, yes?
Anyone who actually uses windows + visualstudio want to comment?
-kurt
http://cwspencer.co.uk/blog/2012/10/getting-useful-c-exception-information-from-visual-studio/
Which down at the bottom says:
You can get WER to generate full crash dumps when your program crashes
and you don’t have a debugger >attached by creating the DWORD registry
keyHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error
Reporting>\LocalDumps\DumpType and setting it to 1 (for mini dumps) or 2
(for full dumps). This will create a dump file >in
%LOCALAPPDATA%\CrashDumps when your program crashes which you can import
into Visual Studio. This is >particularly useful when you are testing on
someone else’s machine where you can’t debug directly.
On Wed, Sep 14, 2016 at 2:02 PM, Joaquim Luis <jl...@ualg.pt> wrote:
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
----
http://schwehr.org
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
