pygmt error kills kernel and exits

[MarkWieczorek]

When trying to make a pygmt figure, I apparently entered some unexpected values. However, even though a useful error message was thrown to the terminal, the python kernel was killed exited.

In [36]: fig = pygmt.Figure()
In [37] : fig.basemap(projection='A0/90/5i', region=[0, 360, -90, 90], frame='afg')
basemap [ERROR]: South boundary cannot be -90.0 for north polar Lambert azimuthal projection

pygmt version: 0.1.1 python 3.7.7 os: macOS

[seisman]

Python exits because GMT calls GMT_exit function (in which the system exit function is called) at Line#3767 in gmt_map.c.

if (GMT->common.R.wesn[YLO] <= -90.0){
    GMT_Report (GMT->parent, GMT_MSG_ERROR, "South boundary cannot be -90.0 for north polar Lambert azimuthal projection\n");
    GMT_exit (GMT, GMT_PROJECTION_ERROR); return false;
}

To avoid calling the system "exit", PyGMT have to set do_not_exit to true in the GMT_Create_Session function. This is done by setting mode to GMT_SESSION_EXTERNAL|GMT_SESSION_NOEXIT, but currently PyGMT calls GMT_Create_Session with mode setting to GMT_SESSION_EXTERNAL only.

I thought setting mode to GMT_SESSION_EXTERNAL|GMT_SESSION_NOEXIT should fix the issue, but the Python code continues running until another segment fault:

basemap [DEBUG]: Map distance calculation will be using great circle approximation with authalic auxiliary latitudes and authalic (R_2) radius = 6371007.1809 m, in meter.
basemap [DEBUG]: Look for file 0/360/-90/90 in /Users/seisman/.gmt
basemap [DEBUG]: Look for file 0/360/-90/90 in /Users/seisman/.gmt/cache
basemap [DEBUG]: Look for file 0/360/-90/90 in /Users/seisman/.gmt/server
basemap [DEBUG]: Look for file 0/360/-90/90 in /Users/seisman/.gmt/server/srtm1
basemap [DEBUG]: Look for file 0/360/-90/90 in /Users/seisman/.gmt/server/srtm3
basemap [DEBUG]: Got regular w/e/s/n for region (0/360/-90/90)
basemap [INFORMATION]: Constructing the basemap
basemap [ERROR]: South boundary cannot be -90.0 for north polar Lambert azimuthal projection
basemap [DEBUG]: Auto-frame interval for axis 0 item 0: d = 90  f = 30
basemap [INFORMATION]: Auto-frame interval for x-axis (item 0): a90f30g90
basemap [DEBUG]: Auto-frame interval for axis 1 item 0: d = 60  f = 15
basemap [INFORMATION]: Auto-frame interval for y-axis (item 0): a60f15g60
basemap [INFORMATION]: Map scale is 7.87402e-05 km per cm or 1:7.87402.
basemap [DEBUG]: Running in PS mode modern
basemap [DEBUG]: Use PS filename /Users/seisman/.gmt/sessions/gmt6.99690/gmt_1.ps-
basemap [DEBUG]: Create hidden PS file /Users/seisman/.gmt/sessions/gmt6.99690/gmt_1.ps-
basemap [DEBUG]: Got session name as pygmt-session and default graphics formats as pdf
basemap [DEBUG]: Entering gmtplot_map_gridlines
basemap [INFORMATION]: Save current gridline information to gmt.history
basemap [DEBUG]: Draw meridian = 0 from -85 to 85
[1]    99690 segmentation fault  ipython

Perhaps GMT should report the error and "exit without calling the exit function" or "return something"? Looks like a GMT bug? @PaulWessel

[PaulWessel]

We need to work towards not calling GMT_exit deep in functions. It was a simple solution that was OK for command line work. However, not sure what is happening here. You pass the NOEXIT bit so API->do_not_exit is set to true, so it should never call exit, just return. Does not mean it could not crash with a SEGV inside GMT - is that what you are seeing?

[seisman]

Line#3766 in gmt_map.c reports the following error first

basemap [ERROR]: South boundary cannot be -90.0 for north polar Lambert azimuthal projection

since API->do_not_exit is true, the GMT_exit function does nothing, then Line#3767 returns false and it looks like the error never occurs. GMT should do something to exit normally, but I have no idea what the SEGV means.

[PaulWessel]

Please make an issue to get rid of the GMT_exit usage, citing this issue as an example.

[seisman]

The issue and similar crashes are fixed in https://github.com/GenericMappingTools/gmt/pull/3401.

The issue will be closed when we bump the minimum required GMT version to 6.1.0.

[PaulWessel]

Always good to get positive reinforcement that drudgery re-coding has a positive effect on others!

[seisman]

The issue was fixed in GMT 6.1.0. Although we can add a test to check it, but it seems unnecessary to me, since the same issue most likely won't happen in GMT again.

Closing the issue.