[gdal-dev] SQLite driver?

Wed Sep 14 14:20:53 PDT 2016

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
<http://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx>
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 <jluis at 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 <jluis at 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 <jluis at 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 at lists.osgeo.org
>>>> >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>> >>
>>>> >> ----
>>>> >> http://schwehr.org
>>>>
>>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
>
> --
> --
> http://schwehr.org
>
>
>
>
>

-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160914/0b85a2b1/attachment-0001.html>