[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #JZT-264094]: netcdf problem

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [netCDF #JZT-264094]: netcdf problem
  • Date: Fri, 20 Feb 2009 13:34:05 -0700
Hi David,

The assertion failure you are seeing means that an internal function,
ncio_spx_get() in libsrc/posixio.c, is being called to read data from
disk, but it's being asked to read 0 bytes.  This should never happen,
so it probably indicates some sort of completely unrelated problem, such
as:

  - a bug in the calling program or in the netCDF library that is
    overwriting the call stack or a memory location outside of its
    scope
  - an intermittent memory error
  - some other hardware or software problem

We have never had another report of this assertion failing, so it seems
unlikely that it is a netCDF library bug.  However, I won't rule out
that possibility, but unless we can reproduce the problem here, we can't
diagnose it or fix it.  That's why we would need a small program that
demonstrates the bug.

Nevertheless, here are a few questions that might help narrow it down:

  - Have you run "make check" on the source distribution used when your
    netCDF library was installed, and did it report any problems?

  - What version of netCDF are you linking against?

  - What platform (computer and operating system) are you using?

  - Do you run other programs on this platform that occasionally fail in
    mysterious ways :-) ?  If so, have you run memory test software?

It might also help to look at the posixio.c file in libsrc and use a
debugger to see what parameters ncio_spx_get() is being called with
when the assertion violation occurs.  That function is only explicitly
called in one place, but it may be called elsewhere through a function
pointer and using a debugger on the core file resulting from the
assertion violation might reveal a way we don't know about that the
function could be called with 0 for the extent.

--Russ

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



Ticket Details
===================
Ticket ID: JZT-264094
Department: Support netCDF
Priority: Critical
Status: Closed