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 <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
