segmentation fault: gasdf.c:3237, index out of bound

[Arlindo da Silva]

On Thu, Feb 21, 2008 at 4:50 AM, Ryo Furue <furue at hawaii.edu> wrote:

> Hi Jennifer,
>
> | You will have to provide all the ncdump -c
> | output from your file -- maybe this will help me to reproduce the
> | error.
>
> I've created a more complete "kit" to reproduce the error:
>
>  http://iprc.soest.hawaii.edu/~furue/tmp/grads-segfault.tar.gz
>
> Download this archive, expand it, descend into the directory,
> and run the GrADS script "segfault.gs" contained in it.
> The archive is about 370MB.
>

I download your file and confirmed that it in fact coredumps with v1.9.0-rc1,
a behavior also confirmed by Hoop.

At GMAO/NASA we are heavy users  HDF-4 and rely on "sdfopen" for reading our
files (through gradshdf). To make a long story short, grads v1.7b9 worked
very well for us, but somewhere along v1.8 a memory leak was introduced that
caused random coredumps when reading  large templated files (memory usage
went into the gigabytes, while v1.7b9 only used 20MB).  After trying to fix
the v1.8/v1.9 sdf code without much luck, I ended up downgrading the sdf
code to the one in v1.7b9. (Patches were applied to fix bugs that had been
fixed in the v1.8/v1.9 series). For internal use we maintain a
v1.9.0-rc1that uses this old version of the sdf code;  binaries built
that way have
been very robust *for us*.  Consistent with what Hoop reports, our internal
version of v1.9.0-rc1 does not coredump on your test dataset above.

Having said that, using the ctl/open route in v1.9 that Jennifer sugests, or
upgrading to v2, is perhaps your best bet. However, if you have a good
reason for staying with v1.9 and sdfopen, I'd be more then glad to share our
binaries and/or sources with you.

      Arlindo

--
Arlindo da Silva
dasilva at alum.mit.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20080222/fd1cc984/attachment.html