I probably should enter this as a bug report on the github page, but I can’t seem to locate it!
Running version: Version 6.3.0_6065f93_2021.07.07
It seems that a segmentation fault error (11) gets issued when feeding a two-column binary file to psxy with the option -gxgap, where “gap” is a number. The same -g option works fine with a text version (i.e., after sending the binary file through gmtconvert).
psxy works fine with my binary file, when -gx option is omitted.
Given this data (in text format, note the gap in the x-coord data, after 394.994):
394.989 1168.18
394.99 1168.18
394.991 1168.19
394.992 1168.2
394.993 1168.25
394.994 1168.33
395.075 1168.03
395.076 1168.28
395.077 1168.25
395.078 1168.23
395.079 1168.22
395.08 1168.21
395.081 1168.2
395.082 1168.19
395.083 1168.19
Save this data as t.txt, and run psxy -gx, for example:
gmt psxy -JX9i/6.5i -R394.95/395.1/1167.5/1168.5 t.txt -W1p -Bxag -Byag -BWeSn -gx0.01 > t.ps
That works just fine.
But, if you convert this sample data to binary (e.g., gmt gmtconvert t.txt -bo2d > t.bin), then run it, like this, you’ll get a segment fault result:
> gmt psxy -JX9i/6.5i -R394.95/395.1/1167.5/1168.5 -bi2d t.bin -W1p -Bxag -Byag -BWeSn -gx0.01 > $OUTMAP
ERROR: Caught signal number 11 (Segmentation fault: 11) at
0 libgmt.6.dylib 0x000000010c0aae40 gmtlib_read_table + 1920
1 ??? 0x0000000000000000 0x0 + 0
Stack backtrace:
0 libgmt.6.dylib 0x000000010c01e8f2 sig_handler + 594
1 libsystem_platform.dylib 0x00007fff6ab9c5fd _sigtramp + 29
2 ??? 0x0000000117f08b8d 0x0 + 4696607629
3 libgmt.6.dylib 0x000000010c04f32a gmtapi_import_data + 4986
4 libgmt.6.dylib 0x000000010c03abcc gmtapi_get_data + 348
5 libgmt.6.dylib 0x000000010c031f42 GMT_Read_Data + 3970
6 libgmt.6.dylib 0x000000010c3b9f2a GMT_psxy + 14266
7 libgmt.6.dylib 0x000000010c042f82 GMT_Call_Module + 2162
8 gmt 0x000000010c008573 main + 1459
9 libdyld.dylib 0x00007fff6a9a3cc9 start + 1