I'm using HDF5 1.8.6 on a Windows7 32-bit system from a data acquisition
C#/.Net application (using the HDFDotNet wrappers).
I've noticed a runtime error(AssertionFailed) popup when I exit my
application after the following behavior:
1.) I open an HDF5 file on a USB drive (or network shared drive)
2.) I start sampling data and storing it to the HDF5 file.
3.) I (rudely) remove the USB drive (or disconnect the network shared drive)
4.) Write exceptions are handled (seemingly appropriately... no crashes)
5.) I close the application.
At this point I get the error, which mentions File:..\..\..\src\H5F.c (Line
1737) and "Expression: f->file_id>0"
I'm assuming the HDF5 library is trying to clean something up and is
confused that it can't find a file it was using... but it seems it should
still be able to recover when it can't. Have I missed something?
Our application consists of 2 separate processes, both utilizing the HDF5
library (for 2 separate purposes). I have been making an assumption that
there would be no interactions between the separate instances of the HDF5
library, correct?
Josh, the assertion comes out of H5F_close (in the unmanaged library).
It appears that the application is trying to close the same file twice
in the context of the same process. (H5F_close sets the file id to -1
and that would trip the assertion in the next round.)
Separate processes (but not threads!) have different file handles etc.
and run different copies of the library (with some code sharing for DLLs).
How do you handle the drive removal, i.e., the WM_DEVICECHANGE message?
I'm using HDF5 1.8.6 on a Windows7 32-bit system from a data acquisition
C#/.Net application (using the HDFDotNet wrappers).
I've noticed a runtime error(AssertionFailed) popup when I exit my
application after the following behavior:
1.) I open an HDF5 file on a USB drive (or network shared drive)
2.) I start sampling data and storing it to the HDF5 file.
3.) I (rudely) remove the USB drive (or disconnect the network shared drive)
4.) Write exceptions are handled (seemingly appropriately... no crashes)
5.) I close the application.
At this point I get the error, which mentions File:..\..\..\src\H5F.c (Line
1737) and "Expression: f->file_id>0"
I'm assuming the HDF5 library is trying to clean something up and is
confused that it can't find a file it was using... but it seems it should
still be able to recover when it can't. Have I missed something?
Thanks for the response. I've placed a breakpoint on the one location that I
call the H5F.close() HDFDotNet wrapper method (that calls H5F_close) and the
application only seems to hit it the one time, so its surprising to hear
this. Are you telling me that I shouldn't call close on the file myself,
that the exit handling does that on its own?
I'm doing no specific handling on the WM_DEVICECHANGE message as I expect
that this would be dealt with in the file-handling system calls. Are you
saying I need to check for these things at the application level?
Josh, you definitely should call H5F.close(). I need to consult
with the local experts on what the library does in response to a device/file
system
removal (if anything). Maybe H5F_close doesn't get called twice. Maybe
the library attempts some kind of forceful cleanup and by the time your
H5F.close() comes
around the file id is already invalid. My inclination is that if you
anticipate
events like drive removal in your application, you should handle them
appropriately.
Thanks for the response. I've placed a breakpoint on the one location that
I call the H5F.close() HDFDotNet wrapper method (that calls H5F_close) and
the application only seems to hit it the one time, so its surprising to hear
this. Are you telling me that I shouldn't call close on the file myself,
that the exit handling does that on its own?
I'm doing no specific handling on the WM_DEVICECHANGE message as I expect
that this would be dealt with in the file-handling system calls. Are you
saying I need to check for these things at the application level?
AFAIK there's a big mess with the error handling in such cases with HDF5, I
have already filed a bug with that quite some time ago. There's another way
to get HDF5 beaten up. Try writing to a memory stick that is almost full.
You get assertions in debug and crash in release. Unfortunately it seems
there has been little testing of the library with such borderline cases
which are, nevertheless, probable. In many cases the reason is simple:
support structures are not initialised properly or are modified and not
rolled back. For example, if for any reason some metadata is not found or it
is not possible to write something to the file, the metadata may be marked
as written but because of the fault not freed, the function jumps out back
to the caller leaving the state of the program inconsistent....
Josh, you definitely should call H5F.close(). I need to consult
with the local experts on what the library does in response to a
device/file
system
removal (if anything). Maybe H5F_close doesn't get called twice. Maybe
the library attempts some kind of forceful cleanup and by the time your
H5F.close() comes
around the file id is already invalid. My inclination is that if you
anticipate
events like drive removal in your application, you should handle them
appropriately.
Thanks for the response. I've placed a breakpoint on the one location that
I call the H5F.close() HDFDotNet wrapper method (that calls H5F_close) and
the application only seems to hit it the one time, so its surprising to
hear
this. Are you telling me that I shouldn't call close on the file myself,
that the exit handling does that on its own?
I'm doing no specific handling on the WM_DEVICECHANGE message as I expect
that this would be dealt with in the file-handling system calls. Are you
saying I need to check for these things at the application level?
I recently attempted an upgrade to HDF5 1.8.7 (as well as the latest
HDF5DotNet wrapper library). After a number of issues with
PInvokeStackImbalance MDA's (which ended with me changing all wrapper calls
back to their original CallingConvention::Cdecl... hmmm...) - I put an
"H5.Close()" call in my application exit code and this appears to have at
least bypassed the "Assertion failed!" call.
It would appear I spoke too soon. Now it seems I am getting
"System.AccessViolationException was unhandled" when calling H5.close (which
calls H5close). I'll continue posting my progress on this.
