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

[netCDF #LUY-161454]: FAIL: tst_longremote3.sh -- test.03 of remote3 fails



There is an unfortunate "bug" of sorts in our dap test server
that is a holdover from the original opendap version.
The problem is that for certain cases, requests are not idempotent;
meaning that making the request twice using the same connection
will result in different outputs. This occurs when you request a string
valued variable as part of your request.
What you are seeing is a (very indirect)
result of that issue. This is probably why the test.03.1.dmp
and test.03.2.dmp work; without looking, I would guess they are
not retrieving any string valued variables.
 
Still, if you do "make check" in the ncdap_test directory, all the tests
should pass (and do for us). So, there must be something else going on,
but what, I am not sure.


> 
> the test.03 of the test set remote3 of the DAP test suite fails when I
> run "make check" of netCDF-4.4.1.1. The log is attached
> 
> At first I thought that the issue would be related to the issue reported
> by Martin
> (https://www.unidata.ucar.edu/support/help/MailArchives/netcdf/msg14240.html
> and https://github.com/Unidata/netcdf-c/issues/899).
> 
> However, the issue appears in netCDF 4.4.1.1, 4.6.1 and the current dev
> version (https://github.com/Unidata/netcdf-c). The generated files
> test.03.1.dmp and test.03.2.dmp agree with the expected files but
> test.03.dmp does not agree.
> 
> The resulting test.03.dmp is attached. I reproduced this test.03.dmp on
> three systems (with different netCDF versions). For some reason, the
> output of ncdump is correct, if the variables s0 (which is not tested in
> the test suite but which I extracted on my own with "...url?s0 ... >
> ...") or s1 are individually extracted. However, if the whole file is
> dumped, ncdump breaks at some point.
> 
> The system, on which I tried all three netCDF versions, is xUbuntu
> 18.04.1 with hdf5 1.8.21, szip 2.1.1 and DAP 3.19.1.
> 
> Cheers,
> Daniel
> 
> 
> 
> --
> Daniel Neumann
> 
> Leibniz Institute for Baltic Sea Research Warnemuende
> Physical Oceanography and Instrumentation
> Seestrasse 15
> 18119 Rostock
> Germany
> 
> phone:  +49-381-5197-287
> fax:    +49-381-5197-114 or 440
> e-mail:address@hidden
> 
> 
> 
> Dear netCDF support team,
> 
> the test.03 of the test set remote3 of the DAP test suite fails when I
> run "make check" of netCDF-4.4.1.1. The log is attached
> 
> At first I thought that the issue would be related to the issue reported
> by Martin
> (https://www.unidata.ucar.edu/support/help/MailArchives/netcdf/msg14240.html
> and https://github.com/Unidata/netcdf-c/issues/899).
> 
> However, the issue appears in netCDF 4.4.1.1, 4.6.1 and the current dev
> version (https://github.com/Unidata/netcdf-c). The generated files
> test.03.1.dmp and test.03.2.dmp agree with the expected files but
> test.03.dmp does not agree.
> 
> The resulting test.03.dmp is attached. I reproduced this test.03.dmp on
> three systems (with different netCDF versions). For some reason, the
> output of ncdump is correct, if the variables s0 (which is not tested in
> the test suite but which I extracted on my own with "...url?s0 ... >
> ...") or s1 are individually extracted. However, if the whole file is
> dumped, ncdump breaks at some point.
> 
> The system, on which I tried all three netCDF versions, is xUbuntu
> 18.04.1 with hdf5 1.8.21, szip 2.1.1 and DAP 3.19.1.
> 
> Cheers,
> Daniel
> 
> 
> 
> --
> Daniel Neumann
> 
> Leibniz Institute for Baltic Sea Research Warnemuende
> Physical Oceanography and Instrumentation
> Seestrasse 15
> 18119 Rostock
> Germany
> 
> phone:  +49-381-5197-287
> fax:    +49-381-5197-114 or 440
> e-mail:address@hidden
> 
> 
> 

=Dennis Heimbigner
  Unidata


Ticket Details
===================
Ticket ID: LUY-161454
Department: Support netCDF
Priority: Normal
Status: Open
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.