Hi,
I am using github GMT and the GMT API example from
https://docs.generic-mapping-tools.org/latest/devdocs/api.html
for some reason, this example and other code using a setup inspired by it now give me a coredump, upon seemingly OK execution, it would seem toward the end of the execute, perhaps associated with the detroy API command, but not sure.
I guess what I am asking is Does the API C example execute fine for people with recent GMT install, and if not, what might be the problem. This used to work fine with a build from, say, a few months ago.
Any ideas? Thanks!
Thorsten
No idea. It does work well for me (on Windows). If you set set (DO_API_TESTS ON) in ConfigUser.cmake (which we do by default in the CI tests) a series of API tests are run (see the testapi_*.c in src) when running the tests. Try that to see if those tests pass.
To find why it’s failing for you I guess that you’ll have to run in through a debugger.
Thanks, I added that flag to the cmake config and made a new build directory, but not seeing those testapi*.c files - will check. I did try to run in debugger before but the error was within the GMT libraries it seemed. Is there a way to keep separate debug and optimized compiles? Wasn’t clear to me from the manual. Thanks!
Those files live in the src dir. After rebuilding with that setting, run the tests with ctest -j?, where ? is the number of cores you want to assign to tests run. Among the > 1200 tests, some should be those testing those api functions.
Regarding the debug, I am sorry but I’m of little help here as I use Windows where troubles are immediate to find (the debugger automatically stops at the crashing point). I remember that Paul had to suffer a bit more with the Xcode but don’t know more. And note that for debugging the test program it needs to be linked against a GMT debug build as well.
I normally build and rebuild with one or another. But you are not obliged to do make install (or ninja install). What I often do is to leave the debug built binaries in the build dir and use those in the debugger. This avoids overwriting the optimized compiles.
Thanks for your replies. I am still having a hard time getting those tests to run (“No tests were found!!!”) but it’s probably something simple I am doing wrong. I’ll try to compile with the debugging on.
As I mentioned before, I have little experience with these tests because they were done for unix only, and me Windows. But you should have received a stack trace, no? Post it here.
the stack trace is not particularly helpful but could indicate that the issue is with ubuntu default libproj?
Odd but, remotely, not totally out of question. When writing grids GMT, if has info for that, tries to add a georeference and for that it may call proj indirectly (via GDAL). But why would it be freeing memory?
Good question! I did some removing and reinstalling of proj and related packages on my Ubuntu system, and the problem went away! Thanks for all those pointers, will be helpful for future debugging (I just made two different build directories sourcing different config files), but in the end it seems to have been the proj package. Rather, some odd mix, perhaps of old and new packages, but I am not sure why.
Thanks again!
Good that you fixed it. But it remains as a smell of something that may come back.
