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

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
> 
> > On Jan 9, 2015, at 12:39 PM, Unidata netCDF Java Support <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