Gmt plot memory allocation - polygon plot

Hi all,

I have issues when running gmt plot on some GPlates-exported polygon data. Plotting crashes when using it with -J (tested Hammer & Robinson) and -G enabled. When using a linear projection all works fine (-G and -W), when only plotting the polygon outline (-W) using a projection -J (W and H proj tested) also works.

This is the output using -V4.

plot [INFORMATION]: Plotting table 0 segment 207
plot [DEBUG]: gmtlib_determine_pole: N = 51 Multiples of 360: 0  Residual: 4.44089e-16 Polygon contains no pole.
plot [DEBUG]: Polar cap: 0
plot [INFORMATION]: Plotting table 0 segment 208
plot [DEBUG]: gmtlib_determine_pole: N = 65 Multiples of 360: 1  Residual: 0 Polygon contains north (CCW) pole.
plot [DEBUG]: Polar cap: 1
plot [DEBUG]: Path already had a detour to the pole, skip adding another detour
plot [DEBUG]: Try to include N pole in polar cap path
plot [DEBUG]: West longitude = -180.  East longitude = 180
plot [DEBUG]: gmtlib_determine_pole: N = 65 Multiples of 360: 1  Residual: 0 Polygon contains north (CCW) pole.
plot [DEBUG]: Make polygon to clockwise
plot [DEBUG]: First longitude = -180.  Last longitude = -180
plot [DEBUG]: Crossing at -180,-nan
plot [DEBUG]: k at point closest to lon -180 is = 1 [n = 65]
psxy (gmtlib_lonpath): Could not reallocate memory [68719476736.00 Gb, 9223372036854775809 items of 8 bytes]	

Unfortunately, I cannot provide you with the reconstructed polygons due to confidentiality reasons. Tracing back the segment number to the actual data, the polygon in question does not cross the north pole.

The data in question plots fine in QGIS/ArcMap and also ogr2ogr doesn’t complain when converting a shp file to ogr_gmt format.

Cheers,
Christian

But can’t you provide us a crashing example that ues only a fraction of you confidential polygon. Or taint it with some noise. Without an example, chances are good that this will not be investigated.

Hi Joaquim - yes, understand. Let me see whether I can find/make up something which allows to reproduce the issue.

Christian

Found the culprit: I believe GPlates detects that the polygon at reconstruction time crosses the pole and generates a GIS-friendly representation by introducing extra points at the dateline causing gmt plot with fill and non-linear projection settings to crash.

Can reproduce this on Win10 running Windows Subsystem for Linux with Debian Buster, GMT v 6.0.0 release and Mac OS 10.13.6 running a locally compiled GMT6 version 3e43ec4 (02.March). Example including a dummy polygon:

#!/bin/bash

cat > pp.gmt  <<END
>
-180    89.0501917
-175  88
-30  85
-20  85
1   87
65   88
180     89.050191
180     90
-180    90
-180    89.050191
END

gmt begin
#--- Works
gmt figure t1_JG pdf
gmt plot pp.gmt -JG0/80/10 -Ba30g10 -Rd -W0.5p,red
gmt plot pp.gmt -W0.1p,green -Sc0.05 

#--- Works too
gmt figure t2_JH pdf
gmt plot pp.gmt -JH10 -Ba30g10 -Rd -W0.5p,red
gmt plot pp.gmt -W0.1p,green  -Sc0.1

#--- Crashes when fill is enabled (also other projs)
gmt figure t3_JGfill pdf
gmt plot pp.gmt -JG0/80/10 -Ba30g10 -Rd -W0.5p,red -Ggrey
gmt plot pp.gmt -W0.1p,green -Sc0.1

#--- works
gmt figure t4_JXfill pdf
gmt plot pp.gmt -JX10 -Ba30g10 -Rd -W0.5p,red -Ggrey
gmt plot pp.gmt -W0.1p,green -Sc0.1

gmt end

Results:
T1:

T2:

T3:

T4:

The crash gives this message (Mac):

gmt(84903,0x7fffb574b380) malloc: *** error for object 0x7fade7c5e7e0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
./test.sh: line 31: 84903 Abort trap: 6           gmt plot p.gmt -JG0/80/10 -Ba30g10 -Rd -W0.5p,red -Ggrey

Cheers,
Christian

Christian, can you please create a bug issue on github with the info needed to reproduce? I will try to fix it. It is unfortunate that my time needs to be spent on dealing with nonsensical polar points introduced into real data to bypass limitations in commercial software, but that is the world we live in.

Thanks Paul - thankfully this is not from commercial software but GPlates :wink: Will also ping John C and let him know. I suspect that it is probably introduced by the OGR_GMT writer in GDAL rather than GPlates itself.

Filed as #3036.

Oh I know, but I thing Gplates may be writing that out as they do that for shapefiles.

That’s right, GPlates is performing dateline wrapping for OGR_GMT same as for Shapefiles. That was probably a mistake (was only meant to be enabled for Shapefiles). I’ll still provide an option to wrap OGR_GMT but have it disabled by default.

Another one to follow up here - this time using the GPlates ‘native GMT’ (xy) export option and the Young et al Static polygons at 0 Ma/present day (polygon simplified by cutting out lines). Here it seems that the replication of the last point is causing the issues:

> rightPlate 0
180	-73.029998
0	-90
0	-90
0.232859	-69.541289
0.238464	-69.049094
0.248351	-69.046975
10.979701	-69.252799
11.5414	-69.224098
32.588006	-64.088087
32.590213	-64.086883
34.438159	-64.338875
34.906163	-64.410876
35.687145	-64.427113
86.406264	-65.118796
90.688983	-64.814861
94.16088	-64.254878
169.590144	-70.162702
177.701996	-73.148002
178.070297	-72.900802
179.118301	-72.953102
179.989883	-73.029116
180	-73.029998
180	-73.029998