# Grdcontour -N with .cpt fails **URL:** \ **Category:** Q&A\ **Created:** [September 4, 2020, 9:15pm UTC](https://forum.generic-mapping-tools.org/t/grdcontour-n-with-cpt-fails/848 "2020-09-04T21:15:11Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![PlanetGus](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/planetgus/32/303_2.png) [@PlanetGus](https://forum.generic-mapping-tools.org/u/PlanetGus)\ **Post date:** [September 4, 2020, 9:15pm UTC](https://forum.generic-mapping-tools.org/t/grdcontour-n-with-cpt-fails/848/1 "2020-09-04T21:15:11Z")
Hi, I tried to (re)-run a script containing this command : > gmt makecpt -Ccork -T0.5/1.5/0.5 -G0/1 -A50 -N \> cold.cpt > gmt grdcontour -R -J -W -C+1 -Ncold.cpt -An $NCvar[$i] For some reason, the -N flag now generates an error : > ERROR: Caught signal number 4 (Illegal instruction: 4) at Playing around with the flags and everything, the problem seems to come from the .cpt : > \> cat cold.cpt > 0.5 174.25/207.62/177.25@50 1 174.25/207.62/177.25@50 L > 1 63/119.88/46.75@50 1.5 63/119.88/46.75@50 B Any idea (I suspected a typo somwhere, but couldn’t find any)? ---
**Author:** ![MarceloBanik](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/marcelobanik/32/479_2.png) [@MarceloBanik](https://forum.generic-mapping-tools.org/u/MarceloBanik)\ **Post date:** [September 5, 2020, 12:33am UTC](https://forum.generic-mapping-tools.org/t/grdcontour-n-with-cpt-fails/848/2 "2020-09-05T00:33:57Z")
I was unable to reproduce the error that you get: ```auto cat \<\ cold.cpt 0.5 174.25/207.62/177.25@50 1 174.25/207.62/177.25@50 L 1 63/119.88/46.75@50 1.5 63/119.88/46.75@50 B EOF gmt grdmath -R0/360/-90/90 -I1 8 4 YLM 1.1 MUL EXCH 0.4 MUL ADD ABS .88 MUL 0.5 ADD = test.nc # something to test gmt grdcontour -R0/360/-90/90 -JW15c -W -C+1 -Ncold.cpt -An test.nc > test.ps ``` generated something that appears reasonable: ![test](https://canada1.discourse-cdn.com/flex047/uploads/gmt/original/1X/232c840bdafb86119d5e2f5ee930fe1fe018636f.png) As far as I could check, GMT changed how it writes the cpt files. ---
**Author:** ![PlanetGus](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/planetgus/32/303_2.png) [@PlanetGus](https://forum.generic-mapping-tools.org/u/PlanetGus)\ **Post date:** [September 5, 2020, 5:36pm UTC](https://forum.generic-mapping-tools.org/t/grdcontour-n-with-cpt-fails/848/3 "2020-09-05T17:36:46Z")
This is very strange. The same kind of lines in a different script works just fine. But no matter how I change the CPT (or assign a single color) it fails in this one. The problem only appears with the -N flag … 😕 ---
**Author:** ![PlanetGus](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/planetgus/32/303_2.png) [@PlanetGus](https://forum.generic-mapping-tools.org/u/PlanetGus)\ **Post date:** [September 5, 2020, 5:54pm UTC](https://forum.generic-mapping-tools.org/t/grdcontour-n-with-cpt-fails/848/4 "2020-09-05T17:54:30Z")
Here’s the debugging log : > gmt grdcontour -R -J -W -C+1 -Ncold.cpt -An ‘path/file?[63]’ -Vd -O -K > > > gmt [DEBUG]: Obtained the ppid from parent: 1321 > > gmt [DEBUG]: Enter: gmtinit\_new\_GMT\_ctrl > > gmt [DEBUG]: GMT-\>session.SHAREDIR = /usr/local/Cellar/gmt/6.1.1/share/gmt > > gmt [DEBUG]: GMT-\>session.HOMEDIR = /Users/Guillaume > > gmt [DEBUG]: GMT-\>session.USERDIR = /Users/Guillaume/.gmt [created] > > gmt [DEBUG]: GMT-\>session.CACHEDIR = /Users/Guillaume/.gmt/cache [created] > > gmt [DEBUG]: GMT: 0. Will try to find subdir=postscriptlight stem = PSL\_custom\_fonts suffix=.txt > > gmt [DEBUG]: GMT: 1. gmt\_getsharepath trying current dir > > gmt [DEBUG]: GMT: 2. gmt\_getsharepath trying USERDIR /Users/Guillaume/.gmt > > gmt [DEBUG]: GMT: 3. gmt\_getsharepath trying USERDIR subdir /Users/Guillaume/.gmt/postscriptlight > > gmt [DEBUG]: GMT: 4. gmt\_getsharepath trying SHAREDIR subdir /usr/local/Cellar/gmt/6.1.1/share/gmt/postscriptlight > > gmt [DEBUG]: GMT: 5. gmt\_getsharepath trying SHAREDIR /usr/local/Cellar/gmt/6.1.1/share/gmt > > gmt [DEBUG]: GMT: 6. gmt\_getsharepath failed > > gmt [DEBUG]: Map distance calculation will be Cartesian > > gmt [DEBUG]: Exit: gmtinit\_new\_GMT\_ctrl > > gmt [DEBUG]: Enter: New\_PSL\_Ctrl > > gmt [DEBUG]: Exit: New\_PSL\_Ctrl > > gmt [DEBUG]: Enter: gmt\_manage\_workflow > > gmt [DEBUG]: Exit : gmt\_manage\_workflow > > gmt [DEBUG]: Enter: PSL\_beginsession > > gmt [DEBUG]: Exit : PSL\_beginsession > > gmt [DEBUG]: Enter: PSL\_setdefaults > > gmt [DEBUG]: Exit : PSL\_setdefaults > > gmt [DEBUG]: Enter: gmtlib\_io\_init > > gmt [DEBUG]: Exit : gmtlib\_io\_init > > gmt [DEBUG]: Enter: gmt\_hash\_init > > gmt [DEBUG]: Exit: gmt\_hash\_init > > gmt [DEBUG]: Enter: gmt\_hash\_init > > gmt [DEBUG]: Exit: gmt\_hash\_init > > gmt [DEBUG]: Enter: gmt\_reload\_settings > > gmt [DEBUG]: The PROJ\_GEODESIC set to Vincenty > > gmt [DEBUG]: Found file gmt.conf > > gmt [DEBUG]: Reading GMT Default parameters from file: gmt.conf > > gmt [DEBUG]: Exit: gmt\_reload\_settings > > gmt [DEBUG]: Enter: gmtlib\_plot\_C\_format > > gmt [DEBUG]: Exit: gmtlib\_plot\_C\_format > > gmt [DEBUG]: Enter: gmtinit\_get\_history > > gmt [DEBUG]: Enter: gmt\_hash\_init > > gmt [DEBUG]: Exit: gmt\_hash\_init > > gmt [DEBUG]: Exit: gmtinit\_get\_history > > gmt [DEBUG]: Initialize FFTW with 4 threads. > > gmt [DEBUG]: GMT\_Create\_Session initialized GMT structure > > gmt [DEBUG]: Loading core GMT shared library: libgmt.dylib > > gmt [DEBUG]: Shared Library # 0 (core). Path = libgmt.dylib > > gmt [DEBUG]: Loading GMT plugins from: /usr/local/Cellar/gmt/6.1.1/lib/gmt/plugins > > gmt [DEBUG]: Shared Library # 1 (supplements). Path = /usr/local/Cellar/gmt/6.1.1/lib/gmt/plugins/supplements.so > > gmt [DEBUG]: gmt\_get\_filename: In: cold.cpt Out: cold.cpt > > gmt [DEBUG]: Found readable file cold.cpt > ERROR: Caught signal number 4 (Illegal instruction: 4) at > 0 libsystem\_c.dylib 0x00007fff693e9fca \_\_chk\_fail\_overflow.cold.1 + 16 > 1 libsystem\_c.dylib 0x00007fff693e9fca \_\_chk\_fail\_overflow.cold.1 + 16 > Stack backtrace: > 0 libgmt.6.1.1.dylib 0x00000001075dd06b sig\_handler + 555 > 1 libsystem\_platform.dylib 0x00007fff695135fd \_sigtramp + 29 > 2 ??? 0x0000000000000080 0x0 + 128 > 3 libsystem\_c.dylib 0x00007fff693e7214 \_\_chk\_fail\_overlap + 0 > 4 libsystem\_c.dylib 0x00007fff693e7769 \_\_sprintf\_object\_size\_chk + 0 > 5 libgmt.6.1.1.dylib 0x00000001077a6750 GMT\_grdcontour + 5784 > 6 libgmt.6.1.1.dylib 0x00000001075fb6a7 GMT\_Call\_Module + 1598 > 7 gmt 0x00000001075d16eb main + 1370 > 8 libdyld.dylib 0x00007fff6931acc9 start + 1 ---
**Author:** ![MarceloBanik](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/marcelobanik/32/479_2.png) [@MarceloBanik](https://forum.generic-mapping-tools.org/u/MarceloBanik)\ **Post date:** [September 5, 2020, 6:52pm UTC](https://forum.generic-mapping-tools.org/t/grdcontour-n-with-cpt-fails/848/5 "2020-09-05T18:52:22Z")
> [@PlanetGus](#): > > gmt [DEBUG]: Reading GMT Default parameters from file: gmt.conf could it be from a older version? Sometimes an old gmt.conf make a mess here. ---
**Author:** ![seisman](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/seisman/32/4_2.png) [@seisman](https://forum.generic-mapping-tools.org/u/seisman)\ **Post date:** [September 5, 2020, 7:25pm UTC](https://forum.generic-mapping-tools.org/t/grdcontour-n-with-cpt-fails/848/6 "2020-09-05T19:25:33Z")
@PlanetGus it would be helpful if you can share your data and full script so that others can reproduce it. ---
**Author:** ![PlanetGus](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/planetgus/32/303_2.png) [@PlanetGus](https://forum.generic-mapping-tools.org/u/PlanetGus)\ **Post date:** [September 8, 2020, 2:33am UTC](https://forum.generic-mapping-tools.org/t/grdcontour-n-with-cpt-fails/848/7 "2020-09-08T02:33:32Z")
@MarceloBanik : No I generate and move my custom .conf in working directory. I tried your suggestion tho… not that. (I wish it was). @seisman : the file is a NetCDF4 (several GB) with 0 and 1. What surprises me is that I have two very similar scripts running the same set of commands, but only this one generates the error with -N flag. Maybe because of the “type” of the data ? (nc\_byte) > ncdump -h $file > > > netcdf data { > > dimensions: > > time = UNLIMITED ; // (2920 currently) > > lat = 361 ; > > lon = 576 ; > > variables: > > byte ar\_binary\_tag(time, lat, lon) ; > > double lat(lat) ; > > double lon(lon) ; > > double time(time) ; > > } UPDATE : > gmt grdinfo $file > > > ERROR: Caught signal number 11 (Segmentation fault: 11) at Maybe the problem is here… but why would it works without the -N flag … ? ---
**Author:** ![PlanetGus](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/planetgus/32/303_2.png) [@PlanetGus](https://forum.generic-mapping-tools.org/u/PlanetGus)\ **Post date:** [September 8, 2020, 3:49am UTC](https://forum.generic-mapping-tools.org/t/grdcontour-n-with-cpt-fails/848/8 "2020-09-08T03:49:33Z")
It somehow works on linux with gmt 6.0.0 (I just copied the script) … I’ll just stick with linux for now and figure out why later… My guess would be there’s a problem with grdcontour and my libraries (macOS), between homebrew and other custom libraries from LaTeX, ghostscript (etc), it’s quite a mess. Thanks.