If the corresponding environment variables are empty, the
uv_us_homedir() and uv_os_tmpdir() return garbage values. The reason
for this situation is the Windows API which doesn't return an error
even if the path is empty.
This PR fixes this problem by checking the return value of the API
call. If it is not an error and the length of the value is less than 3,
uv_us_homedir() and uv_os_tmpdir() will return UV_ENOENT.
Fixes: https://github.com/libuv/libuv/issues/2328
This was incorrectly mapped originally, which makes for confusing error
messages about an EPIPE if a program happens to (unwisely) set PIPE_WAIT
on the handle. It is unclear to me if libuv should try to handle this in
some meaningful way, and very unclear what that way would look like, but
at least expose this to the caller with the correct errno translation.
CreateProcessW() in uv_spawn() on Windows will fail with
ERROR_BAD_EXE_FORMAT if attempting to run a file that is not
an executable.
Refs: https://github.com/libuv/libuv/issues/2348
Make it less likely for the thread-local error value to get
clobbered between performing the operation and checking the result.
Refs: https://github.com/libuv/libuv/issues/4338
It might happen that only using `WaitForSingleObject()` with timeout 0
could return WAIT_TIMEOUT as the process might not have been signaled
yet. To improve things, first use `GetExitCodeProcess()` and check
that `status` is not `STILL_ACTIVE`. Then, to cover for the case that the exit
code was actually `STILL_ACTIVE` use `WaitForSingleObject()`. This could
still be prone to the race condition but only for that case.
Add a process options flag to enable the optional behavior. Most users
are likely recommended to set this flag by default, but it was deemed
potentially breaking to set it by default in libuv.
Co-authored-by: Kyle Edwards <kyle.edwards@kitware.com>
Passing a socket name without a trailing nul byte to uv_pipe_bind2() or
(on Windows) uv_pipe_connect2() resulted in reading beyond the end of
the name buffer when copying or converting it.
Fix that by copying the socket name to temporary storage first and add
the trailing nul byte explicitly.
Add a check for embedded nul bytes in the socket name.
Fix a small memory leak in the Windows error path of uv_pipe_bind2().
There is no length at which this gets truncated on Windows. The
underlying file system will just not successfully connect to a longer
path (in WTF-16 characters), which will return an error asynchronously
with the existing API.
Refs: #4040
This was incorrectly dropped by #4030, where previously connecting to ""
might fail eventually, now instead it would return EINVAL and then fail
to initialize the struct or call the callback.
Add uv_thread_setpriority for setting priority for threads created by
uv_thread_create. Add uv_thread_getpriority for getting thread priority.
For Linux by default, if the scheduling policy is SCHED_OTHER and the
priority is 0, we need to set the nice value.
Fixes: https://github.com/libuv/libuv/issues/4051
uv_os_uname() on Windows queries the registry value "HKEY_LOCAL_MACHINE\
SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName" to fill
uv_utsname_t. If calling application was compiled for x86 and run on a
x86_64 host, that query is redirected to "Computer\HKEY_LOCAL_MACHINE\
SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\ProductName"
instead.
For whatever reason, the value of 'ProductName' in the 32-bit registry
section on 64-bit Windows sometimes differs from the 64-bit equivalent
value and is inaccurate (e.g. containing the data
"Windows 10 Enterprise" while the 64-bit value accurately contains
"Windows 10 Pro").
Adds the 'KEY_WOW64_64KEY' security descriptor when opening the
appropriate registry key so that the value of ProductName is always
taken from the primary registry on 64-bit systems, regardless of
compiled architecture. The descriptor is safely ignored on 32-bit hosts.
As promised in #2970, this attempts to migrate code to a common set of
utilities in a common place in the code and use them everywhere. This
also exports the functionality, since the Windows API with
WideCharToMultiByte is fairly verbose relative to what libuv and
libuv's clients typically need, so it is useful not to require clients
to reimplement this conversion logic unnecessarily (and because Windows
is not 64-bit ready here, but this implementation is.)
Make sure this handle is functional. The Windows kernel seems to have a
bug that if the first use of AssignProcessToJobObject is for a Windows
Store program, subsequent attempts to use the handle with fail with
INVALID_PARAMETER (87). This is possilby because all uses of the handle
must be for the same Terminal Services session. We can ensure it is
tied to our current session now by adding ourself to it. We could
remove ourself afterwards, but there doesn't seem to be a reason to.
Secondly, we start the process suspended so that we can make sure we
added it to the job control object before it does anything itself (such
as launch more jobs or exit).
Fixes: https://github.com/JuliaLang/julia/issues/51461
Adjust include order to avoid redefining `CTL_CODE`, `FILE_READ_ACCESS`,
and `FILE_WRITE_ACCESS`. Without this, compilation shows:
```
...\um\winioctl.h(273): warning C4005: 'CTL_CODE': macro redefinition
...\src\win\winapi.h(4497): note: see previous definition of 'CTL_CODE'
...\um\winioctl.h(320): warning C4005: 'FILE_READ_ACCESS': macro redefinition
...\src\win\winapi.h(4488): note: see previous definition of 'FILE_READ_ACCESS'
...\um\winioctl.h(321): warning C4005: 'FILE_WRITE_ACCESS': macro redefinition
...\src\win\winapi.h(4492): note: see previous definition of 'FILE_WRITE_ACCESS'
```
The initial run of timers shouldn't happen if uv_stop() has been run
before uv_run() was called, and for backwards compatibility they also
shouldn't run if they have been unref'd before calling uv_run().
Recent versions of gcc have started emitting warnings about the liberal
type casting inside the QUEUE macros. Although the warnings are false
positives, let's use them as the impetus to switch to a type-safer and
arguably cleaner approach.
Fixes: https://github.com/libuv/libuv/issues/4019
This commit adds the ability to dump core when sending the `SIGQUIT`
signal on Windows. The change reads in the current registry setting for
local dumps, and attempts to write out to that location before killing
the process. See [collecting-user-mode-dumps] for registry and pathing
details. This behavior mimics that of the dumps created by the typical
Windows Error Reporting mechanism.
[collecting-user-mode-dumps]: https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps
The worker pool calls all callbacks locally within the queue. So the
value of nevents doesn't properly reflect that case. Increase the number
of events directly from the worker pool's callback to correct this.
In order to properly determine if the events_waiting counter needs to be
incremented, store the timeout value at the time the event provider was
called.
The maximum number of times timers should run when uv_run() is called
with UV_RUN_ONCE and UV_RUN_NOWAIT is 1. Do that by conditionally
calling timers before entering the while loop when called with
UV_RUN_DEFAULT.
The reason to always run timers at the end of the while loop, instead of
at the beginning, is to help enforce the conceptual event loop model.
Which starts when entering the event provider (e.g. calling poll).
Other than only allowing timers to be processed once per uv_run()
execution, the only other noticeable change this will show is if all the
following are true:
* uv_run() is called with UV_RUN_NOWAIT or UV_RUN_ONCE.
* An event is waiting to be received when poll is called.
* Execution time between the call to uv_timer_start() and entering the
while loop is longer than the timeout.
If all these are true, then timers that would have executed before
entering the event provider will now be executed afterward.
Fixes: https://github.com/libuv/libuv/issues/3686
Co-authored-by: Momtchil Momtchev <momtchil@momtchev.com>
This code would previously get confused between rounds of the barrier
being called and a thread might incorrectly get stuck (deadlock) if the
next round started before that thread had exited the current round.
Avoid that by not starting the next round in++ before out-- has reached
zero indicating that all threads have left the prior round.
And fix it that on Windows by replacing the implementation with the one
from unix. There are some awkward platform-specific redirection here
with an extra malloc that is not needed on Win32, but that will be fixed
in libuv v2.
Fixes: https://github.com/libuv/libuv/issue/3872
The call to uv__cwd() always returns a new allocation. The previously
allocated utf16_buffer needs to be free'd before passing it in to
receive the next allocation.
File system operations may return uid and gid values, which we may want
to pretty-print. We already have the code for getting information for
the current user, so just need to add a parameter to make it exposed for
every user. We expose information about groups in a similar manner also.
In Node.js, fs.readlink() on a non-symlink file used to throw an UNKNOWN
error on Windows. This change maps ERROR_NOT_A_REPARSE_POINT to
UV_EINVAL, so that now it throws EINVAL just like other platforms.
This is handled explicitly in `fs__readlink`, since elsewhere it might
map to EPERM instead (such as in `link`).
