Re: 980421: SunOS 5.5.1, nc_close() wild free()-ing?

>To: Phil Sackinger <address@hidden>
>cc: address@hidden,
>cc: address@hidden,
>cc: address@hidden,
>cc: address@hidden,
>cc: address@hidden,
>cc: address@hidden,
>cc: address@hidden,
>cc: address@hidden,
>cc: address@hidden,
>cc: address@hidden
>From: "Larry A. Schoof" <address@hidden>
>Subject: Re: SunOS 5.5.1, nc_close() wild free()-ing?
>Organization: Sandia National Labs
>Keywords: 199804211622.KAA16815

Hi Larry,

> This is the third report (in the last month) of problems related to malloc
> and free within EXODUS (3.00) and/or netCDF (3.4) on Solaris 5.5.1; no
> other platforms have generated these errors!  I fixed one that Chris Moen
> reported by using the NC_SHARE flag on the nc_open and nc_create calls.
> This caused the metadata to be flushed to the file more often, otherwise
> it was being corrupted under very rare conditions.  I never located the
> root cause of that problem (after trying to track it down for 3 days), but
> my solution just fixed the symptom.
> 
> On Tue, 21 Apr 1998, Phil Sackinger wrote:
> 
> > 
> > Lately I've experienced unusual memory problems under SunOS 5.5.1 with
> > our finite element application program (goma) that uses the EXODUS II
> > API and netCDF.
> > 
> <stuff deleted>
> > 
> > The ex_close() routines do appear to call some routines like
> > rm_stat_ptr() that call free() also, but Purify evidently indicates
> > the problems originate with the free() calls occurring in nc.c
> > 
> > Since I'm not familiar with the data structures like "struct obj_stats
> > **obj_ptr" used in EXODUS II nor the "struct NC" used by netCDF, I
> > cannot easily determine if they are being misused to free() something
> > they shouldn't.
> > 
> 
> I've looked carefully at the instances of obj_stats and I don't think
> they're the culprits, but I'll look at them again.  The ball is in my
> court for this.
> 
> > 
> > At this point I'm almost ready to suspect the Solaris malloc() of
> > being broken. Building the whole thing on another platform should be a
> > a good check to see if this might be the case.
> > 
> 
> This is a possibility I've considered for quite a while.
> 
> > 
> > Thanks in advance.
> > 
> > 
> > -Phil Sackinger, Sandia National Labs, Albuquerque, NM 87185-0826 USA
> > 
> 
> I'll take the action on this.
> 
> Larry

I just sent Phil a report of the results of running nc_test, the
extensive test program released with netCDF 3.4, under Purify 4.1 on
SunOS 5.6.  It worked fine, reporting no problems.  We don't have access
to a SunOS 5.5.1 platform on which to test, but no one else has reported
any malloc/free problems with netCDF 3.x.  However, the fact that the
problems go away with NC_SHARE set sounds suspicious.  Please keep us
informed about what you discover.

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu