segmentation fault

Thu Jun 1 11:26:58 EDT 2006

Thanks Warren.

Since your post, I have encountered new, but predictable segmentation
faults.

I am trying to write binary to ascii.  Works fine up to some threshold
then segmentation fault core dumps.   E.g., I can successfully dump 248
days but not 921 (of slp, north america).

So, in the interim, I will have to do as you suggest:  break out my binary
dump into smaller chunks.

But, I've submitted this post in hopes someone has found a resolution for
us.  Your memory leak notion is interesting.

Here is my Grads environment:
v1.9b4.  using pre-compiled binaries
netCDF. gradsnc.
Linux, RH7.3

Paul Willis

On Thu, 25 May 2006 07:42:31 +0200, Warren Tennant
<tennant at WEATHERSA.CO.ZA> wrote:

>Hi Paul
>
>There have been several posts about "segmentation faults". We have
>experienced them a lot on our RedHat systems (8.0, 9.0, Fedora core
>2,3,4 and even Centos 4.x). The problem is widespread but rather
>elusive. However, it seems the sdfopen with a template option is the
>quickest way of "fishing" for a segmentation fault. We had a post last
>year from Kilian Hagemann who suggested a memory leak (see below my
>email) ...
>
>I must admit that we too have stayed with the pre-compiled binaries as
>compiling from source requires a little more intellect than I posses,
>despite the noble attempts by Patrice Dumas to point us all in the right
>direction.
>
>My solution for now: run the scripts in smaller chunks to avoid the seg
>fault, and wait for those who know more about C and Linux to solve the
>issue.  Another thought I had: does the stack limits controlled by the
>"ulimit" command have any bearing on this? Perhaps the small stack size
>(by default in RedHat) constrains something.
>
>Regards to all
>Warren
>
>Kilian Hagemann wrote:
>******************
>
>Hi there,
>
>I wrote a little script to check for global max/min values of NCEP data
from
>1993-2004 when I noticed that when it got further and further my system
>started thrashing. Initial memory requirement: About 16MB, after every
>further year of averaging an additional ~10MB and towards the end of the
>script a whopping 780MB!!!! Smells like memory leak/improper pointer
>management to me...
>
>The script is attached, and as long as you have the NCEP netcdf data
somewhere
>available (change the ncepPath variable in the script) it should run fine.
>
>I built 1.9b3 from source using all the extra components except the dods
>interface. But that shouldn't make a difference. Let me know if you need
any
>further information.
>
>Regards,
>
>--
>Kilian Hagemann
>
>Climate Systems Analysis Group
>University of Cape Town
>Republic of South Africa
>Tel(w): ++27 21 650 2748
>
>------------------------------------------------------------------------
>
>#!/usr/local/grads/bin/grads -lbc
>* Copyright 2004 by Kilian Hagemann
>*
>* Script to extract relevant NCEP data for SOM analysis to find an
optimally representative 12 month period for MM5 wind simulation
>* WARNING: The min/max detection for automatic scaling works ONLY with a
patched version of grads (setting mfcmn.warnflg to 0 in grads.c in version
1.9b3), otherwise the min() and max() functions output a whole lot of
garbage which chokes the script
>
>ncepPath = '/obs-a/ncep/ncep.new/'
>startYear = 1993
>endYear = 2004
>
>var.1 = uwnd
>var.2 = vwnd
>var.3 = hgt
>var.4 = omega
>var.5 = rhum
>var.6 = shum
>var.7 = air
>
>*air.sig995
>*omega.sig995
>*pr_wtr.eatm
>*pres.sfc
>*rhum.sig995
>*slp.sig995
>*uwnd.sig995
>*vwnd.sig995
>
>nvars = 7
>
>* first find the global maximum and minimum values
>* uncomment following while loop to find these
>nvar = 1
>while (nvar <= nvars)
>    global_max = -9999
>    global_min = 9999
>    year = startYear
>    while (year <= endYear)
>        'sdfopen 'ncepPath%var.nvar'.'year'.nc'
>* the dimension arguments in the following have been manually determined
>        'd max(max(max('var.nvar',x=7,x=15),y=22,y=28), t=1, t=1460)'
>        max = subwrd(result, 4)
>        if (max > global_max)
>            global_max = max
>        endif
>        'd min(min(min('var.nvar',x=7,x=15),y=22,y=28), t=1, t=1460)'
>        min = subwrd(result, 4)
>        if (min < global_min)
>            global_min = min
>        endif
>        say '   In year 'year' min/max 'var.nvar' are 'min'/'max' over
the selected domain'
>        'close 1'
>        year = year + 1
>    endwhile
>    say
>    say 'Global min/max 'var.nvar' are 'global_min'/'global_max' over the
selected domain'
>    say
>    nvar = nvar + 1
>endwhile
>
>
>'quit'
>
>******************************************************************
>
>Willis, Paul ENV:EX wrote:
>
>>My posting below was premature.  I am still experiencing the same
problems
>>when attempting to use the TEMPLATE option with the DDF.  Jennifer and
>>Diane have been kindly working with me off-listserve but without
>>resolution.
>>
>>here is what I know:
>>
>>My environment:     linux RH7.3
>>
>>GrADS install:      I reinstalled with pre-compiled binary exe.  no
change.
>>
>>Data file corruption:  I downloaded a fresh set of data files.  no
change.
>>
>>Hoop's 'sdfopen' merge:  see previous thread.  While this resolves the
>>offset and missing value warnings, the environment is unstable and core
>>dumps (segmentation faults) make it unworkable.
>>
>>My questions du-jour:
>>
>>1) Has anyone had compatibility problems running rh7.3?
>>
>>2) Jennifer has 'grepped' GrADS source code and has not found the source
>>of this warning:
>>
>>"-- using -1e+15 insteade data type for "missing_value"
>>
>>Does this look familiar to anyone.  note, I have not messed with the
GrADS
>>source code on my machine.
>>
>>3)  Suggestions for further debugging of either the offset problem when
>>using the DDF, or with segmentation faults when using the 'sdfopen'
merge?
>>
>>
>>Thanks.
>>
>>Paul Willis
>>
>>
>>