[netCDFJava #YCN-767203]: Using native NetCDF 4 library with assertions enabled

Hi Peter:

Its working ok for me:

Netcdf nc_inq_libvers='4.3.2 of Apr 23 2014 15:17:23 $' isProtected=true
Nc4Iosp.isClibraryPresent = true
Writing version netcdf3
file.exists() = true
file.length() = 65612
file.delete() = true
Writing version netcdf4
file.exists() = true
file.length() = 507
file.delete() = true

strange. I also downloaded latest release and tried again:

Netcdf nc_inq_libvers='4.3.3-rc3 of Jan 14 2015 14:41:42 $' isProtected=true
Nc4Iosp.isClibraryPresent = true
Writing version netcdf3
File written target/test/tmp/test.nc
file.exists() = true
file.length() = 65612
file.delete() = true
Writing version netcdf4
File written target/test/tmp/test.nc
file.exists() = true
file.length() = 507
file.delete() = true

perhaps try reinstalling. run ncdump on a netcdf4 file to convince yourself 
that your install is ok. then tyr the java coe again.

John

> Hi John,
> 
> See the attached Java code.
> 
> Peter
> 
> address@hidden> wrote:
> 
> > ok, can you give me a small test program that reproduces the problem?
> >
> > John
> >
> > > FYI I also tried updating to Java HDF version 2.11 to and got a similar
> > error from my test program, though more informative:
> > >
> > > > Writing version netcdf3
> > > > Jan 22, 2015 12:27:49 PM ncsa.hdf.hdf5lib.H5 loadH5Lib
> > > > INFO: HDF5 library: jhdf5
> > > > Jan 22, 2015 12:27:49 PM ncsa.hdf.hdf5lib.H5 loadH5Lib
> > > > INFO:  successfully loaded from java.library.path
> > > > Found HDF 5 version = false
> > > > file.exists() = true
> > > > file.length() = 65612
> > > > file.delete() = true
> > > > Writing version netcdf4
> > > >  Netcdf nc_inq_libvers='4.3.2 of Oct 20 2014 09:49:08 $'
> > isProtected=false
> > > >  Exception in thread "main" java.io.IOException: -101: NetCDF: HDF
> > error
> > > >     at ucar.nc2.jni.netcdf.Nc4Iosp.create(Nc4Iosp.java:2253)
> > > >     at ucar.nc2.NetcdfFileWriter.create(NetcdfFileWriter.java:794)
> > > >     at NetCDFTest.main(NetCDFTest.java:39)
> > >
> > >
> > > Peter
> > > --
> > > Peter Hollemans <address@hidden>, Terrenus Earth Sciences
> > > Web: http://www.terrenus.ca  Phone: +1 (778) 533-2896
> > >
> > > > On Jan 22, 2015, at 11:35 AM, Peter Hollemans <address@hidden>
> > wrote:
> > > >
> > > > I'm using the latest version available here:
> > > >
> > > > ftp://ftp.unidata.ucar.edu/pub/netcdf-java/v4.5/toolsUI-4.5.jar
> > > >
> > > > Peter
> > > > --
> > > > Peter Hollemans <address@hidden>, Terrenus Earth Sciences
> > > > Web: http://www.terrenus.ca  Phone: +1 (778) 533-2896
> > > >
> > address@hidden> wrote:
> > > >>
> > > >> Hi Peter: what version netcdf-java? if no using latest 4.5, can you
> > try with that and report? thanks
> > > >>
> > > >>> Hi John,
> > > >>>
> > > >>> I've tracked the problem down a little further, and found the the
> > string "not a valid cdfid" comes from the HDF JNI library and the error is
> > _not_ related to assertions:
> > > >>>
> > > >>>> Beanlet-Pro:test_case_1 phollema$ strings libjhdf.jnilib | grep
> > "not a valid cdfid"
> > > >>>> %d is not a valid cdfid
> > > >>>>
> > > >>>
> > > >>> which is from my Mac, or similarly in Linux:
> > > >>>
> > > >>>> Beanlet-Pro:test_case_1 phollema$ strings libjhdf.so | grep "not a
> > valid cdfid"
> > > >>>> %d is not a valid cdfid
> > > >>>>
> > > >>>
> > > >>> I've been able to reduce the code to just the essentials needed to
> > recreate the error on Mac, but on Linux I've not been able to reproduce
> > using the same code.  Essentially, I do these steps in the attached code:
> > > >>>
> > > >>> Step 1) Use the Java NetCDF library to create and write a NetCDF 3
> > file
> > > >>> Step 2) Use the Java HDF object interface to check if the file
> > created is HDF 5
> > > >>> Step 3) Use the Java NetCDF library to create and write a NetCDF 4
> > file
> > > >>> Step 4) Use the Java HDF object interface to check if the file
> > created is HDF 5
> > > >>>
> > > >>> When I run on Mac, Step 3 never completes and my program exits with
> > "netcdf: 65536 is not a valid cdfid" just when I perform the create() call.
> > > >>>
> > > >>> Peter
> > > >>> --
> > > >>> Peter Hollemans <address@hidden>, Terrenus Earth Sciences
> > > >>> Web: http://www.terrenus.ca  Phone: +1 (778) 533-2896
> > > >>>
> > address@hidden> wrote:
> > > >>>>
> > > >>>> hi peter:
> > > >>>>
> > > >>>> can you try it with 4.5.4 version of java-netcdf?
> > > >>>> if still persists, send me the file so i can try to reproduce.
> > > >>>> thanks
> > > >>>> John
> > > >>>>
> > > >>>>> Full Name: Peter Hollemans
> > > >>>>> Email Address: address@hidden
> > > >>>>> Organization: NOAA
> > > >>>>> Package Version: 4.5.3
> > > >>>>> Operating System: Mac OS X 10.10.1
> > > >>>>> Hardware: MacBook Pro 13" 2011
> > > >>>>> Description of problem: Hello!
> > > >>>>>
> > > >>>>> I have an interesting problem which I think I've tracked down to
> > > >>>>> assertions.  If I run my Java code with assertions enabled just
> > for my
> > > >>>>> package (-ea:noaa.coastwatch...), I seem to have assertions
> > enabled for
> > > >>>>> the NetCDF 4 library that's JNA mapped via Nc4Iosp as well.  If I
> > turn off
> > > >>>>> assertions (ie: I just run as normal), then my code runs to
> > completion
> > > >>>>> (no errors thrown, but no assertions checked either).  The message
> > I'm
> > > >>>>> getting with assertions enabled looks like this (running from ant):
> > > >>>>>
> > > >>>>> [java]
> > > >>>>> [java] ***** class noaa.coastwatch.io.CFNCWriter *****
> > > >>>>> [java] Testing writing of NetCDF version 3 format ... OK
> > > >>>>> [java] Testing writing of NetCDF version 4 format ...  Netcdf
> > nc_inq_libvers='4.3.2 of Oct 20 2014 09:49:08 $' isProtected=false
> > > >>>>> [java] netcdf: 65536 is not a valid cdfid
> > > >>>>> [java]
> > > >>>>> [java] Java Result: 3
> > > >>>>>
> > > >>>>> I can see the nc_inq_libvers message is coming from the Nc4Iosp
> > class
> > > >>>>> after it runs the Native.loadLibrary() call, but I can't see
> > anywhere in
> > > >>>>> the Java code that the "not a valid cdfid" is coming from, so I
> > assume
> > > >>>>> it must be from the NetCDF 4 native layer.
> > > >>>>>
> > > >>>>> Any ideas on how to fix this aside from going into the NetCDF 4
> > source
> > > >>>>> and trying to determine why the assertion (if that's what it is) is
> > > >>>>> being tripped?  I thought, maybe there's a way to tell the
> > loadLibrary
> > > >>>>> call to not propagate the JVM assertion mode into the native layer,
> > > >>>>> but couldn't find any documentation on if that's possible.
> > > >>>>>
> > > >>>>> Peter
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>> Ticket Details
> > > >>>> ===================
> > > >>>> Ticket ID: YCN-767203
> > > >>>> Department: Support netCDF Java
> > > >>>> Priority: Normal
> > > >>>> Status: Open
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >> Ticket Details
> > > >> ===================
> > > >> Ticket ID: YCN-767203
> > > >> Department: Support netCDF Java
> > > >> Priority: Normal
> > > >> Status: Open
> > > >>
> > > >
> > >
> > >
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: YCN-767203
> > Department: Support netCDF Java
> > Priority: High
> > Status: Open
> >
> >
> 
> 

Ticket Details
===================
Ticket ID: YCN-767203
Department: Support netCDF Java
Priority: High
Status: Closed