Hi,
I am trying to make a grd mask out of a south polar xyz file. The input data seems to be OK
minmax tmp.1.VSH.dat
tmp.1.VSH.dat: N = 60225 <-179.639653937/180> <-90/-35.4593858369> <6.09066152573/6.41782569885>
but when I try to make a mask
> grdmask -Rg -I1 -NNaN/1/1 -Gtmp.grd -S100k tmp.1.VSH.dat -fg
ERROR: Caught signal number 11 (Segmentation fault) at
/usr/local/lib/libgmt.so.6(GMT_grdmask+0x2609)[0x7f65d6199329]
[0x0]
Stack backtrace:
/usr/local/lib/libgmt.so.6(sig_handler_unix+0xf1)[0x7f65d5f8d391]
/lib/x86_64-linux-gnu/libc.so.6(+0x43090)[0x7f65d5bf3090]
/usr/local/lib/libgmt.so.6(GMT_grdmask+0x2609)[0x7f65d6199329]
/usr/local/lib/libgmt.so.6(GMT_Call_Module+0x3cf)[0x7f65d5e294ff]
grdmask(main+0x343)[0x7f65d648c703]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7f65d5bd4083]
grdmask(_start+0x2e)[0x7f65d648d8de]
grdmask [core] 6.4.0_07159ed_2022.05.28 [64-bit]
I put the input file here
https://www.dropbox.com/s/v4m7mdnzncacy0x/tmp.1.VSH.dat.gz?dl=0
not sure how to simplify the problem. Am I just getting something wrong with the syntax, or is that an actual bug? Seems to be independent of how the region is specified, in that -R-180/180/-90/-70 doesn’t work either.
Thanks!
Hmm, normally is the contrary. Windows detects tinny memory corruptions and *nix not.
That to say that it works fine for me.
grdmask -Rg -I1 -NNaN/1/1 -Gtmp.grd -S100k tmp.1.VSH.dat -fg -V
grdmask [INFORMATION]: Enable all available threads (up to 12)
grdmask [INFORMATION]: Processing input table data
grdmask [INFORMATION]: Nodes completely outside the search radius will be set to NaN
grdmask [INFORMATION]: Nodes completely inside the search radius will be set to 1
grdmask [INFORMATION]: Nodes on the search radius boundary will be set to 1
grdmask [INFORMATION]: Reading Data Table from File tmp.1.VSH.dat
grdmask [INFORMATION]: Writing grid to file tmp.grd
grdmask [INFORMATION]: Detected 360 inconsistent values at north pole. Values fixed by setting all to average row value.
grdmask [INFORMATION]: Detected 125 inconsistent values along periodic east boundary of grid. Values fixed by duplicating west boundary.
Thanks for testing. So UNIX seems to throw a core dump and windows doesn’t. I’m not sure how to recompile all with -g with the cmake system to see where the dump occurs, if this
ERROR: Caught signal number 11 (Segmentation fault) at
/usr/local/lib/libgmt.so.6(GMT_grdmask+0x2609)[0x7fa00e639329]
[0x0]
Stack backtrace:
/usr/local/lib/libgmt.so.6(sig_handler_unix+0xf1)[0x7fa00e42d391]
/lib/x86_64-linux-gnu/libc.so.6(+0x43090)[0x7fa00e093090]
/usr/local/lib/libgmt.so.6(GMT_grdmask+0x2609)[0x7fa00e639329]
/usr/local/lib/libgmt.so.6(GMT_Call_Module+0x3cf)[0x7fa00e2c94ff]
grdmask(main+0x343)[0x7fa00e927703]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7fa00e074083]
grdmask(_start+0x2e)[0x7fa00e9288de]
isn’t enough info.
To build a debug version I use this in my ConfigUser.cmake (Toggle between Release and Debug)
set(CMAKE_BUILD_TYPE Release)
but it should work from command line by adding
-DCMAKE_BUILD_TYPE=Debug
Thanks, here’s what the debugger says. Line 564 of grdmask.c
(gdb) run -R0/360/-90/-70 -I1 -NNaN/1/1 -Gtmp.grd -S100k tmp.1.VSH.dat -fg -V
Starting program: /usr/local/bin/grdmask -R0/360/-90/-70 -I1 -NNaN/1/1 -Gtmp.grd -S100k tmp.1.VSH.dat -fg -V
[Thread debugging using libthread_db enabled]
Using host libthread_db library “/lib/x86_64-linux-gnu/libthread_db.so.1”.
[New Thread 0x7ffff2c50700 (LWP 11874)]
[New Thread 0x7ffff2440700 (LWP 11875)]
[New Thread 0x7fffedc30700 (LWP 11876)]
grdmask [INFORMATION]: Processing input table data
grdmask [INFORMATION]: Nodes completely outside the search radius will be set to NaN
grdmask [INFORMATION]: Nodes completely inside the search radius will be set to 1
grdmask [INFORMATION]: Nodes on the search radius boundary will be set to 1
grdmask [INFORMATION]: Reading Data Table from File tmp.1.VSH.dat
Thread 1 “grdmask” received signal SIGSEGV, Segmentation fault.
0x00007fffff51a6bf in GMT_grdmask (V_API=, mode=, args=)
at /home/twb/progs/src/gmt/src/grdmask.c:564
564 if (node_is_set[ij]) continue; /* Already set */
(gdb) where
#0 0x00007fffff51a6bf in GMT_grdmask (V_API=, mode=, args=)
at /home/twb/progs/src/gmt/src/grdmask.c:564
#1 0x00007fffff2133fe in GMT_Call_Module (V_API=0x80531a0, module=, mode=8, args=0x7ffffffed9c0)
at /home/twb/progs/src/gmt/src/gmt_api.c:12654
#2 0x0000000008001708 in main (argc=, argv=0x7ffffffed9b8) at /home/twb/progs/src/gmt/src/gmt.c:112
How I (vaguely) interpret it is that the ij counter overflew the allocated memory of node_is_set but can’t help more from here. Let’s wait that Paul checks if it crashes too in Mac, … but that damn Xcode has proven so liberal in the past.
Yeah, it’s a bit tricky since a simple range check on ij doesn’t lead to an error condition, but putting a print statement would indicate that colu is returned as -1 which blows things up.
I’m confused by the range of allowable values for these indices but if I add
f((((int)colu) < 0)||(((int)ij) >= ((int)Grid->header->size))||(((int)ij) < 0)){
fprintf(stderr,“error: ij %i size %i rowu %i colu %i\n”,(int)ij,(int)Grid->header->size,rowu,colu);
fprintf(stderr,“error: ii %i col %i col start %i col end %i\n”,
(int)ii,(int)col,col_start,col_end);
exit(-1);
}
before the offending call that coredumps, I get
error: ij 8031 size 9125 rowu 20 colu -1
error: ii -1 col -361 col start -361 col end 361
my guess is that d_col[rowu] should not be 361 but rather be limited to 360 here.
Thanks for posting the data. I should be able to reproduce this but it may take me a few days (flying back to Oxford on Saturday so lots of airplane debugging time then).
It’s quite strange that colu = -1 as on unix that variable is typedefed to unsigned int (the openmp_intcast).
Meanwhile, it probably will work for you if you ask grdmask to create a pixel registered grid.
We have a branch that I hope fixes this issue - are you able to switch to it and build and test?
Thanks much! Did, and tests look OK! Super!
Now in master (I’ve just merge the branch).