[gdal-dev] SQLite driver?

Wed Sep 14 14:55:02 PDT 2016

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 <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/6d63ba3a/attachment.html>