hdp dumpsds exits 0 after a failed read, silently producing a truncated dump

Open
  • Is something wrong?
#925 0 comments 0 reactions 1 assignee View on GitHub

@bmribler is already working on this.

Since Sep 21, 2026.

Assessment

This issue has not been assessed yet.

Description

Summary

When hdp dumpsds fails partway through reading an SDS, it prints HDP ERROR>>> to
stderr and writes a truncated dump, but still exits with status 0. A caller that
checks the exit status — a shell pipeline, a build step, a batch conversion script —
accepts the truncated output as a complete, successful dump.

This is inconsistent with hdp's own handling of file-level errors, which correctly
return 1.

Version
$ hdp -V
hdp, HDF Version 4.4 Release 0, August 31, 2026

Built from the hdf4.4.0.tar.gz source release (SHA256 f69afb63...3e286, matching the
published hdf4.4.0.sha256sums.txt), CMake 4.2.3, Apple clang 14.0.0, macOS 12,
-DBUILD_SHARED_LIBS=OFF -DHDF4_BUILD_TOOLS=ON.

Steps to reproduce

Any SDS whose data cannot be fully read will do. The case here is an AIRS granule with a
single internally corrupted gzip chunk, so 122 of its 135 along-track scans read back and
the 123rd does not:

$ hdp dumpsds -b -n radiances -o out.bin AIRS.2014.06.10.047.L1B.AIRS_Rad.v5.0.22.0.G14161111358.hdf
HDP ERROR>>> in sdsdumpfull: SDreaddata failed for sds_id(262147).
HDP ERROR>>> in printSDS_BINARY: sdsdumpfull failed for 3'th SDS.
HDP ERROR>>> in dsd: printSDS_BINARY failed for file AIRS...hdf

$ echo $?
0

$ stat -f%z out.bin
104441760          # complete SDS is 115570800 bytes

The output is short by 11,129,040 bytes — 13 of the 135 scans — with no indication in the
exit status. The ASCII path (hdp dumpsds -n radiances <file>) behaves the same way:
error on stderr, exit 0.

The granule is public from GES DISC (AIRIBRAD v005, Earthdata Login required):

https://data.gesdisc.earthdata.nasa.gov/data/Aqua_AIRS_Level1/AIRIBRAD.005/2014/161/AIRS.2014.06.10.047.L1B.AIRS_Rad.v5.0.22.0.G14161111358.hdf

It is one of three granules whose corruption GES DISC has confirmed in
https://forum.earthdata.nasa.gov/viewtopic.php?t=8227 — but the exit-status behaviour is
independent of that data issue and should reproduce with any unreadable SDS chunk.

Expected

A failed read should be reflected in the exit status, so that output known to be
incomplete is not silently accepted downstream.

Contrast: file-level errors already do the right thing
$ hdp dumpsds -n radiances no_such_file.hdf ; echo $?
HDP ERROR>>> in dsd: no_such_file.hdf is not an HDF or netCDF file.
HDP ERROR>>> in do_dumpsds: dsd failed.
1

$ hdp notacommand ; echo $?
1

So hdp distinguishes these cases today — dsd failing to open a file propagates, while
printSDS_BINARY / printSDS_ASCII failing mid-dump does not.

Possibly related

Minor, and arguably intended, but in the same area: a requested SDS that does not exist is
reported on stdout rather than stderr, also with exit 0:

$ hdp dumpsds -n NoSuchSDS file.hdf ; echo $?
SDS with name 'NoSuchSDS': not found
0

#857 (closed) asked for an option to keep dumping after a failure and to enable the error
stack, which is adjacent to this but about continuing rather than about the exit status.

Dominant language
C
Stars
22
Forks
27
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from HDFGroup/hdf4

All issues in HDFGroup/hdf4

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.