Build with VS2015 crashes in GDAL call

[joa-quim]

Hi,

I managed to build osmcoastline on Windows (VS2015) in spite of many troubles not mentioned in instructions (using unistd.h that doesn't exist on VS, ::write(...) not existing in name space and others). Does it ever was build with VS2015?

But ok, I did it but now it crashes at

https://github.com/osmcode/osmcoastline/blob/master/include/gdalcpp.hpp#L132

apparently because m_driver is NULL. I confess that this is too much C++ for me and can't even understand what this is supposed to do

#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 a function definition and is tested to be NULL? Anyway, the point is that it crashes.

[joto]

I am not aware that anybody every tried to build this on Windows. I have fixed the unistd.h issue now, but I can't test it, because I don't have a Windows system. If you have any other fixes, please tell me and I'll try to add them.

I can't think of any reason why there could be a crash on that line. Can you tell us exactly what program you called with what input data and what command line? And add a stack trace if possible.

[joa-quim]

Ok, I (partially) found out why it crashed. The issue was that it was finding a gdal dll that was built without sqlite support. Don't understand why it crashes on the line that is supposed to warn the user about that fact, but the fact is that it did.

After solving that the program advances a bit but crashes again, now when exiting the function (in output_database.cpp) OutputDatabase::add_error_point. Again, I have no idea why and the debugger just says

Critical error detected c0000374
osmcoastline.exe has triggered a breakpoint.

The code that I run is the runtest.sh test. And it advances up to this point

V:\builOsm>compileds\VC14_64\bin\osmcoastline --debug --verbose --overwrite --output-lines --output-polygons=both --output-rings -o testdata.db C:/programs/compa_libs/osmcoastline/testdata.osm
Enabled debug option
[ 0:00] Using SRS 4326 for output. (Change with the --srs/s option.)
[ 0:00] Writing to output database 'testdata.db'. (Was set with the --output-database/-o option.)
[ 0:00] Removing database output file (if it exists) (because you told me to with --overwrite/-f).
[ 0:00] Will create geometry index. (If you do not want an index use --no-index/-i.)
[ 0:01] Reading from file 'C:/programs/compa_libs/osmcoastline/testdata.osm'.
[ 0:01] Reading ways (1st pass through input file)...
[ 0:01]   There are 19 nodes where the coastline is not closed.
[ 0:01]   There are 36 coastline rings (16 from a single way and 20 from multiple ways).
[ 0:01] Memory used: current: 0 MBytes, peak: 0 MBytes
[ 0:01] Reading nodes (2nd pass through input file)...
<crash>

And, as you already saw, I made a PR the changes needed to build with VS. But I need also to edit the src/CMakeList.txt to reflect variables that I had to declare in the cmake call so that it finds the dependencies in mys system (more than those officially mentioned, e.g. getopt)

[joto]

I just checked and the test works fine on Linux (I just changed the code to use some non-existing driver name). No idea about the second problem. I guess it must have something to do with library incompatibilities, one compiled with different compiler version than the other or something like it. Unfortunately I can't help with that.

Normally you should not need to change anything in CMakeList.txt, but can set the needed variables on the cmake command line.

Maybe this helps: The programs in https://github.com/osmcode/osm-gis-export repository also needs a lot of the same libraries and there are some batch files there to compile on windows. See build-*.bat and appveyor.yml.

[joa-quim]

Regarding the compiler version, I have all the dependencies built with the same compiler (lot of work to get there) so that can't be the reason.

As for the CMakeList.txt, I had to add for example

include_directories (${GEOS_C_INCLUDE_DIR})
target_link_libraries(osmcoastline ${OSMIUM_IO_LIBRARIES} ${GDAL_LIBRARIES} ${GEOS_C_LIBRARIES} ${GETOPT_LIBRARY})

otherwise it wouldn't find neither geos_c.h and the geos_c & getopt libraries. I can see in your scripts that you don't set GEOS but I had to due to otherwise compiler/linking errors.

Another thing that I saw in those scripts is that you also use boost. I didn't and there was no building complains. Is it really necessary? Because avoiding it is a relieve due to its gigantic nature.

On a side note, do you know GMT ? Because our plans are to migrate our GSHHS coastlines to use OSM ones and this attempt of mine is a exploratory work to see how the osmcoastline tool could help us when that work really starts.

[joto]

Osmcoastline doesn't need boost. The batch scripts are for different programs which do need boost. Don't expect that you can just use them.

CMakeList changes: Ah, okay, that makes sense. But if you don't tell me those things I can't fix them. I have added a few changes.

GMT: Please stay on topic here. It is difficult enough fixing problems when there is one issue per problem. If you have a question, open another issue or ask on a mailing list or so.

[joa-quim]

Ok, good to know that boost is not need.

The CMakeList changes: I didn't include them in my PR because I was not sure if it would cause a problem in the unix build.

The GMT: No questions here, it was just to let you know.

[joa-quim]

It turns out that the crash only occurs in debug builds. With Release ones the example runs fine. From my experience the debug crashes can result from the use of non-initialized variables that in debug builds get whatever the memory has there while in release builds they initialized to zero. Char variables not initialized to NULL are one of those examples.

Another aspect of my experience is that Visual Studio is much more strict to small memory errors than gcc or clang.

[joto]

Can you provide a stack trace? Otherwise I can't see how we can avance to get this resolved.

[joa-quim]

I'm sorry. Cannot get a good stack trace, otherwise I would have found more about the real crashing reason. I guess that you would have to try to build it yourself in debug mode to see what's happening. If this was C I'm sure I could help but C++ is just too dark for me.

[joto]

I can't help here, because I don't have access to a Windows machine. Leaving this open until somebody can provide more information.

[joto]

No more information in the last 2 years. Closing.