grdproject crash

[anbj]

The command substitution for -R in the command below expands to:

$ gmt mapproject -WE -RIHO6 -JS0/90/10c
-R-13.13780447767911/60.1123216369926/46.78593973599926/72.38367793452505+r

$ gmt grdproject @earth_relief_05m $(gmt mapproject -WE -RIHO6 -JS0/90/10c) -GIHO6.nc -Ju+31/1:1 -F -C 
gmt [WARNING]: Remote dataset given to a data processing module but no registration was specified - default to gridline registration (if available)
ERROR: Caught signal number 11 (Segmentation fault) at
/home/anbj/gmt/build/lib/libgmt.so.6(gmt_xy_to_geo+0x2d)[0x7f28ec7307cd]
[0x0]
Stack backtrace:
/home/anbj/gmt/build/lib/libgmt.so.6(sig_handler_unix+0xc0)[0x7f28ec6d7700]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x13140)[0x7f28ec55a140]
/home/anbj/gmt/build/lib/libgmt.so.6(gmt_xy_to_geo+0x2d)[0x7f28ec7307cd]
/home/anbj/gmt/build/lib/libgmt.so.6(gmt_wesn_search+0x159)[0x7f28ec730939]
/home/anbj/gmt/build/lib/libgmt.so.6(gmt_map_perimeter_search+0x6f)[0x7f28ec75459f]
/home/anbj/gmt/build/lib/libgmt.so.6(gmt_map_setup+0x411)[0x7f28ec7551d1]
/home/anbj/gmt/build/lib/libgmt.so.6(gmt_init_module+0x1c51)[0x7f28ec70aa21]
/home/anbj/gmt/build/lib/libgmt.so.6(GMT_grdproject+0x166)[0x7f28ec89dda6]
/home/anbj/gmt/build/lib/libgmt.so.6(GMT_Call_Module+0x38e)[0x7f28ec5e4c3e]
gmt(main+0x546)[0x561550072736]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f28ec395d0a]
gmt(_start+0x2a)[0x5615500735aa]

Change the command above to use @earth_relief_06m or coarser and there is no crash. @earth_relief_05m (and finer?) cause crash.

[Esteban82]

I try with 05m and it works. I run on GMT6.4.0 on Win64.

gmt grdproject @earth_relief_05m $(gmt mapproject -WE -RIHO6 -JS0/90/10c) -GIHO6.nc -Ju+31/1:1 -F -C
gmt.exe [WARNING]: Remote dataset given to a data processing module but no registration was specified - default to gridline registration (if available)
grdblend [NOTICE]: Remote data courtesy of GMT data server oceania [http://oceania.generic-mapping-tools.org]

grdblend [NOTICE]: SRTM15 Earth Relief at 05x05 arc minutes reduced by Gaussian Cartesian filtering (9.3 km fullwidth) [Tozer et al., 2019].
grdblend [NOTICE]:   -> Download 180x180 degree grid tile (earth_relief_05m_g): S90W180
grdblend [NOTICE]:   -> Download 180x180 degree grid tile (earth_relief_05m_g): S90E000

[anbj]

Why this discrepancy?! Thanks @Esteban82. I’ll try to flush the remote data and try again.

[Esteban82]

But on my Ubuntu 22.04 with GMT6.5 it failed

Remote dataset given to a data processing module but no registration was specified - default to gridline registration (if available)
ERROR: Caught signal number 11 (Segmentation fault) at
/usr/local/lib/libgmt.so.6(gmt_xy_to_geo+0x31)[0x7f6b0228cad1]
[0x0]
Stack backtrace:
/usr/local/lib/libgmt.so.6(sig_handler_unix+0xf1)[0x7f6b02231c31]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f6b01ed2520]
/usr/local/lib/libgmt.so.6(gmt_xy_to_geo+0x31)[0x7f6b0228cad1]
/usr/local/lib/libgmt.so.6(gmt_wesn_search+0x171)[0x7f6b0228cc61]
/usr/local/lib/libgmt.so.6(gmt_map_perimeter_search+0x83)[0x7f6b022b10d3]
/usr/local/lib/libgmt.so.6(gmt_map_setup+0x6f8)[0x7f6b022b1ff8]
/usr/local/lib/libgmt.so.6(gmt_init_module+0x1c41)[0x7f6b0226e3a1]
/usr/local/lib/libgmt.so.6(GMT_grdproject+0x19e)[0x7f6b023fdc5e]
/usr/local/lib/libgmt.so.6(GMT_Call_Module+0x3ae)[0x7f6b021372ae]
gmt(main+0x518)[0x55b6a7b948d8]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7f6b01eb9d90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7f6b01eb9e40]
gmt(_start+0x25)[0x55b6a7b95755]

[anbj]

Interesting. We’ve had some of these ‘Linux only’ crashes before.

[Esteban82]

Interesting. We’ve had some of these ‘Linux only’ crashes before.

Notice that I used different GMT versions (6.4 OK, 6.5 Failed).

[anbj]

Yes. I suspect win vs linux cause, instead of the version and regression.

[Esteban82]

Altough, I just installed 6.4 on my ubuntu and still fails.

[anbj]

Just tried the same command on WSL (Windows 10), if it helps in any way (though same crash as in first post by the look of it):

$ gmt grdproject @earth_relief_05m $(gmt mapproject -WE -RIHO6 -JS0/90/10c) -GIHO6.nc
-Ju+31/1:1 -F -C
gmt [WARNING]: Remote dataset given to a data processing module but no registration was specified - default to gridline registration (if available)
ERROR: Caught signal number 11 (Segmentation fault) at
/home/anbj/gmt/build/lib/libgmt.so.6(+0x1b6e44)[0x7fd52c4b8e44]
[0x7fd521d5c000]
Stack backtrace:
/home/anbj/gmt/build/lib/libgmt.so.6(sig_handler_unix+0xc0)[0x7fd52c44f700]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x13140)[0x7fd52c2e7140]
/home/anbj/gmt/build/lib/libgmt.so.6(+0x1b6e44)[0x7fd52c4b8e44]
/home/anbj/gmt/build/lib/libgmt.so.6(gmt_wesn_search+0x159)[0x7fd52c4a8939]
/home/anbj/gmt/build/lib/libgmt.so.6(gmt_map_perimeter_search+0x6f)[0x7fd52c4cc59f]
/home/anbj/gmt/build/lib/libgmt.so.6(gmt_map_setup+0x411)[0x7fd52c4cd1d1]
/home/anbj/gmt/build/lib/libgmt.so.6(gmt_init_module+0x1c51)[0x7fd52c482a21]
/home/anbj/gmt/build/lib/libgmt.so.6(GMT_grdproject+0x166)[0x7fd52c615e56]
/home/anbj/gmt/build/lib/libgmt.so.6(GMT_Call_Module+0x38e)[0x7fd52c35cc3e]
gmt(main+0x546)[0x7fd52c906736]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7fd52c113d0a]
gmt(_start+0x2a)[0x7fd52c9075aa]

[PaulWessel]

Crashes for me with macOS so should be debuggable once I have time.

[anbj]

Yay! Please assemble your chair.

[PaulWessel]

Done. Took less time than what Skatteetaten told me my "application" for moving to Norway and be updated in Folkeregisteret would take to be processed (2-12 weeks). I foolishly thought I was already Norwegian and could come and go as I please.

[anbj]

Welcome home, Sir!

[PaulWessel]

I have diagnosed the problem: For unclear reasons, the internal map width (which should not really be used) is very large, and when divided by step length we get the number of nodes to search in x and y. This is very large and when we allocate lon and lat arrays to hold the coordinates of the oblique search area we run into 32-bit truncations on the allocation front and we get less than requested and finally we exceed bounds. I know elsewhere we have special checks for mapproject and grdproject to not do this so will need to see what we do there to avoid these extreme paths. I can fix the crash by doing 64-bit integer math but we still do not want to search paths with over 2^32 coordinates though.

[PaulWessel]

Well, the test is there but it fails to detect that this is grdproject because

print GMT->init.module_name
(const char *) $1 = 0x0000600000009070 "gmt"

This is within grdproject so not sure yet why module is "gmt". Well, it is because that assignment happens at the end of gmt_init_module but we are being called to deal with the remote data and at that point the init.module_name is still the previous caller which is gmt. So need to intervene somehow. Will see how to do this.

[anbj]

Fixed in #7062.