ncdump fails on s390x

[dschwoerer]

To report a non-security related issue, please provide:

• master ; v4.9.2 ; v4.9.0 (output from 43abd69)

• Fedora 36 on s390x

• The attached file somefile.nc.zip cannot be read with ncdump -h somefile.nc

• The file was generated on s390x as part of the test suite; it can be read without issues on x86_64

netcdf somefile {
dimensions:
	x = 1 ;
	y = 54 ;
	z = 1 ;
	t = UNLIMITED ; // (0 currently)
	char36 = 36 ;
variables:
[...]
	char run_id(char36) ;
		run_id:description = "UUID for this simulation" ;
[...]
	double dx(x, 
NetCDF: Invalid dimension ID or name
Location: file /home/dave/netcdf-c/ncdump/ncdump.c; fcn do_ncdump_rec line 1782

The next dimension would be y - i.e. id 1, but the id is read as 0x1000000. Note that the dimension id for char36 is correctly read as 4.

[WardF]

Thanks for the report; it's taking a bit, but I'm setting up a debian s390x system via qemu that hopefully well help debug this!

[dschwoerer]

I have currently access to a s390x vm - so if there is something I can help with let me know. Unfortunately I don't know the code, so debugging is a bit difficult for me.

podman run --arch=s390x --rm -it debian is another way to get easy access to a s390x qemu container.

[WardF]

Thanks; I haven't used podman but will look into it. I see there is also an s390x qemu container available via docker. I should have looked at this yesterday, perhaps. But thank you, we'll see about getting this sorted out!

[opoplawski]

I don't know if this helps, but this is from a gdb session with netcdf 4.8.1:

nclistget (l=0x2aa0006bf60, index=16777216) at ../libdispatch/../../libdispatch/nclist.c:106
106       if(l == NULL || l->length == 0) return NULL;
(gdb) print l->length
$10 = 5
(gdb) s
107       if(index >= l->length) return NULL;
(gdb) print index
$11 = 16777216
(gdb) bt
#0  nclistget (l=0x2aa0006bf60, index=16777216) at ../libdispatch/../../libdispatch/nclist.c:107
#1  0x000003fff7dc6c56 in nc4_find_dim (grp=<optimized out>, dimid=<optimized out>, dim=0x3ffffff7bc0, dim_grp=0x3ffffff7bc8) at ../libsrc4/../../libsrc4/nc4internal.c:443
#2  0x000003fff7d844d8 in HDF5_inq_dim (ncid=<optimized out>, dimid=<optimized out>, name=0x3ffffff7f3c "x", lenp=<optimized out>) at ../libhdf5/../../libhdf5/hdf5dim.c:151
#3  0x000003fff7d37868 in nc_inq_dimname (ncid=ncid@entry=65536, dimid=<optimized out>, name=name@entry=0x3ffffff7f3c "x") at ../libdispatch/../../libdispatch/ddim.c:416
#4  0x000002aa0000df76 in do_ncdump_rec (ncid=ncid@entry=65536, path=<optimized out>) at ../../ncdump/ncdump.c:1750
#5  0x000002aa000049ae in do_ncdump (path=0x2aa00017b40 "somefile.nc", ncid=65536) at ../../ncdump/ncdump.c:2016
#6  main (argc=<optimized out>, argv=<optimized out>) at ../../ncdump/ncdump.c:2456

Going up to 4:

#4  0x000002aa0000df76 in do_ncdump_rec (ncid=ncid@entry=65536, path=<optimized out>) at ../../ncdump/ncdump.c:1750
1750             NC_CHECK( nc_inq_dimname(ncid, var.dims[id], dim_name) );
(gdb) print id
$14 = 1
(gdb) print var
$15 = {name = "dx\000T_VERSION\000rom", '\000' <repeats 239 times>, type = 6, tinfo = 0x2aa00205940, ndims = 2, dims = 0x2aa00207c40, natts = 3, has_fillval = 0, fillvalp = 0x0, has_timeval = 0, timeinfo = 0x0, is_bnds_var = 0, 
  fmt = 0x0, locid = 0, val_tostring = 0x0}
(gdb) print var.dims
$16 = (int *) 0x2aa00207c40
(gdb) print *var.dims
$17 = 0
(gdb) print var.dims[id]
$18 = 16777216

[dschwoerer]

Is there something I can do to help move this along?

[WardF]

Thank you; I'm adding this to the list and will be opening broader s390x/big endian issue which links to this and other related issues, so that we can make a dedicated push towards getting these issues resolved.

[edhartnett]

I believe this is an endianness problem and is fixed by #3285

It would be good if we had an actual ncdump test for this...