[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[netCDF #UBS-599337]: Abort on reading damaged HDF5 file
- Subject: [netCDF #UBS-599337]: Abort on reading damaged HDF5 file
- Date: Mon, 15 May 2017 11:15:33 -0600
Hello,
This is something we can look at, absolutely; I'll need to review the code in
question to see if there's a reason why it's being handled the way it is, but
it might make more sense to return an error instead.
Thanks for reporting this, we'll take a look.
Have a great day!
-Ward
> Full Name: Ruurd Dorsman
> Email Address: address@hidden
> Organization: VORtech
> Package Version: 4.4.1.1
> Operating System: Linux, Windows
> Hardware:
> Description of problem:
>
> Dear Sir/Madam,
>
> We are currently trying to build an application that robustly reads data
> from netCDF files (in HDF5 file format). Because it is essential for
> our application that it continues on errors, we have written extensive
> tests. One of the tests we perform is trying to read a valid netCDF
> file of which we have changed the first byte to 0x00 to mimic file
> corruption. This causes the program to abort with an assertion error.
>
> As far as I can tell, the error is triggered by line 2866 of nc4file.c
> because the variable hdf_file is zero. This variable is set in the same
> file on line 294 because the function H5Fis_hdf5 recognizes the file is
> not valid HDF5 and the fallback (checking the first 4 bytes of the file
> for a known file format) also produces no result.
>
> The assertion is followed by a comment that the assert(0) should
> never happen, but apparently it can sometimes occur in rare
> circumstances. Replacing the line with something like:
>
> return NC_ENOTNC;
> should fix the problem.
>
> Is this fix something you would be willing to include in the next release
> of netCDF?
>
> Kind regards,
> Ruurd Dorsman
>
>
Ticket Details
===================
Ticket ID: UBS-599337
Department: Support netCDF
Priority: Normal
Status: Closed
===================
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.