Fix a possible range error when a win32 file watcher gets destroyed while waiting.

This is not a final solution, but avoids the fatal error and replaces it with, at worst, bogus change events being reported.
This commit is contained in:
Sönke Ludwig 2017-11-17 18:35:48 +01:00
parent 88bfabf557
commit 7cc6bec14a

View file

@ -77,16 +77,24 @@ final class WinAPIEventDriverWatchers : EventDriverWatchers {
{
import std.conv : to;
auto handle = overlapped.hEvent; // *file* handle
auto id = WatcherID(cast(int)handle);
auto slot = () @trusted { return &WinAPIEventDriver.threadInstance.core.m_handles[handle].watcher(); } ();
if (dwError != 0) {
// FIXME: this must be propagated to the caller
//logWarn("Failed to read directory changes: %s", dwError);
return;
}
auto handle = overlapped.hEvent; // *file* handle
auto id = WatcherID(cast(int)handle);
/* HACK: this avoids a range voilation in case an already destroyed
watcher still fires a completed event. It does not avoid problems
that may arise from reused file handles.
*/
if (handle !in WinAPIEventDriver.threadInstance.core.m_handles)
return;
auto slot = () @trusted { return &WinAPIEventDriver.threadInstance.core.m_handles[handle].watcher(); } ();
ubyte[] result = slot.buffer[0 .. cbTransferred];
do {
assert(result.length >= FILE_NOTIFY_INFORMATION.sizeof);