Windows, should we assert CloseHandle errors?
Thomas Stüfe
thomas.stuefe at gmail.com
Mon Nov 21 11:02:44 UTC 2016
Hi all,
so, the other day I found a bug (in our code, not in the original OpenJDK)
which was caused by a double OS handle close. Similar to a double free, but
with handles.
On Windows, many OS resources are accessed via kernel handles, which are
closed via the generic CloseHandle() API. Numerical values for HANDLE seem
to be handed out sequentially, and the chance to reuse a numerical handle
value is high. This makes Windows OS coding susceptible to
double-handle-free-errors because the chance of a double free freeing
another handle in a completely unrelated piece of code is high.
In our case, due to an tiny error when merging our additions to OpenJDK
upstream sources, we accidentally closed the handle in ProcessImpl twice.
This broke completely unrelated code sections, just because they happened
to allocate a new handle between the first the the second CloseHandle()
call in ProcessImpl, which happened to have the same numerical value as the
former ProcessImpl handle.
My question: due to the difficulty of tracking down these errors, should we
not assert() if CloseHandle() fails with INVALID_HANDLE_VALUE (many call
sites of CloseHandle() in hotspot do not check the return code)? For a
double free, we would catch all cases where between the first and the
second CloseHandle() call this handle was not handed out again. I think
this would help a lot in these cases. The argument against asserting is
that any code - also third party native code - may cause a double free and
hence an assert in our code.
What do you think?
Kind Regards, Thomas
More information about the hotspot-runtime-dev
mailing list