The value INVALID_HANDLE_VALUE could in theory be a valid memory address,
so the analyzer is confused and thinks either we have a memroy leak
or we try to free a fixed address.
The used method for initalizing and registering the handle creators
had certain disadvantages like that it was necessary to have the creators
initialized before the first call to CreateFile. In case of comm it
wouldn't have been possible to open an comm port without calling any
other call related function first.
Now the handle creators are initialized the first time CreateFile is
called. This way it is also possible to ensure a certain order of the
handler invocations.
This commit also splits out the client side named pipe code from
the generic file handling (now called generic.c instead of file.c) and
uses the new handle creator infrastructure to register.
Allows the WinPR HANDLE functions WaitForSingleObject and
WaitForMultipleObjects to signal in case of write events.
This is used by CreateFileDescriptor and SetEventFileDescriptor,
which got an API change accomodating for this new feature.
This resulted in huge memory leaks - 8MB per thread, depending on
the system's default stack size.
The leak happend even if CloseHandle() was correctly used to "detach"
the thread but WaitForSingleObject was never called.
winpr is now always build as single library.
The build option MONOLITHIC_BUILD doesn't influence this behavior anymore.
The only exception is winpr-makecert-tool which is still build as extra
library.
This obsoletes complex_libraries for winpr.
RegisterHandleCloseCb() is also useful to don't get a circular dependency, a better synchronization must be find out...
This reverts commit 8f3b3fa573.
Since commit 5e09e37d42 was basically unfixable,
here is a slightly different approach that should hopefully solve all
discovered issues and race conditions.
- refcount is only relevant for servermode
- refcount was used uninitialized in clientmode
- credit for fix goes to @bmiklautz
Bug was introduced by 5e09e37d42
