Needed for compile with `-msse2` (such as implied by `-march=pentium4`)
for the i686-w64-mingw64 target triple. This seems like a header mistake, but
we can work-around it here by including the header explicitly.
Refs: https://sourceforge.net/p/mingw-w64/bugs/712
PR-URL: https://github.com/libuv/libuv/pull/2083
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
In the original PR, the ifdef conditional was reversed,
leading to the old code-path still being used.
This also reduces some of the redundancy in the conditional checks,
by factoring out the common test.
And fixes a divergence in functionality kFSEventsRenamed =>
kFSEventStreamEventFlagItemRenamed
And actually includes the part of the original PR to kqueue that enabled
watching files with fsevents!
Fixes: https://github.com/libuv/libuv/pull/387
PR-URL: https://github.com/libuv/libuv/pull/2082
Refs: https://github.com/libuv/libuv/pull/1572
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
When releasing key with Alt pressed, the reported event has
LEFT_ALT_PRESSED state flag set. This confuses libuv, making it think
that Alt+numpad combination is used. This fixes this issue by removing
the check for state flag. Checking if VirtuakKeyCode is set to VK_MENU
is enough to detect the Alt+numpad case.
Fixes: https://github.com/libuv/libuv/issues/2111
PR-URL: https://github.com/libuv/libuv/pull/2114
Reviewed-By: Refael Ackermann <refack@gmail.com>
Guard against sending the handle over the UNIX domain socket twice
when the first sendmsg() didn't write all bytes.
The changes to src/win partially undo changes made earlier this year,
see the referenced pull request for details.
Libuv never made promises about the value of `req->send_handle` at
different points in time so this should be a safe, non-breaking change.
No tests because this particular condition is hard to hit reliably
across platforms. I spent a lot of time trying to write one but it
turned out hideously complex, and worse, flaky.
Fixes: https://github.com/libuv/libuv/issues/2086
PR-URL: https://github.com/libuv/libuv/pull/2097
Refs: https://github.com/libuv/libuv/pull/1843
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Refactor uv__write() to make an upcoming fix easier to implement.
PR-URL: https://github.com/libuv/libuv/pull/2097
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
In AIX, fs watch feature leverages AHAFS function.
According to AHAFS, monitoring of events does not
begin until the monitoring application issues a select()
or a blocking read() call. In edge cases where the watch
request as well as fs event both occurs in single event
loop cycle, we miss the event, as the event monitors are
created but not yet registered in the current cycle,
instead only enqueued into the poll structure, that will
be taken up with the OS on the loop edge only.
Trigger a select call in-line on the monitoring fd, that
tells AHAFS to kick-start the moitoring.
Fixes: https://github.com/libuv/libuv/issues/2118
PR-URL: https://github.com/libuv/libuv/pull/2123
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This reverts commit e94c184c7c.
Concerns were raised about the suitability of this policy and I, for
one, agree with them.
Fixes: https://github.com/libuv/libuv/issues/2098
PR-URL: https://github.com/libuv/libuv/pull/2122
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
On Android, pthread is part of the C standard library. Hence, there is
no need to specify -lpthread when building for Android.
PR-URL: https://github.com/libuv/libuv/pull/2110
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
On Windows, `fs__open()` maps `UV_FS_O_DIRECT` to
`FILE_FLAG_NO_BUFFERING`.
When `access` is only `FILE_GENERIC_READ` this succeeds, but when
`access` is `FILE_GENERIC_WRITE` this returns an error:
```
0x00000057, ERROR_INVALID_PARAMETER, The parameter is incorrect.
```
The reason is that `FILE_GENERIC_WRITE` includes `FILE_APPEND_DATA`,
but `FILE_APPEND_DATA` and `FILE_FLAG_NO_BUFFERING` are mutually
exclusive:
```
FILE_GENERIC_WRITE = STANDARD_RIGHTS_WRITE |
FILE_WRITE_DATA |
FILE_WRITE_ATTRIBUTES |
FILE_WRITE_EA |
FILE_APPEND_DATA |
SYNCHRONIZE
```
This incompatibility between access and attribute flags does not appear
to be documented by Microsoft for `FILE_FLAG_NO_BUFFERING` but it is
indirectly documented under [NtCreateFile](https://bit.ly/2rm5wRT):
```
FILE_NO_INTERMEDIATE_BUFFERING
The file cannot be cached or buffered in a driver's internal buffers.
This flag is incompatible with the DesiredAccess FILE_APPEND_DATA flag.
```
The solution is to remove `FILE_APPEND_DATA` from the access flags when
`FILE_FLAG_NO_BUFFERING` is set. Note that this does not prevent
appends, since `FILE_GENERIC_WRITE` also includes `FILE_WRITE_DATA`,
which in turn allows appends.
PR-URL: https://github.com/libuv/libuv/pull/2102
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Don't use a buffer with static lifetime to store intermediate results,
use a stack-allocated one.
PR-URL: https://github.com/libuv/libuv/pull/2065
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Insecure and unnecessary. Replace them with a call to snprintf().
PR-URL: https://github.com/libuv/libuv/pull/2065
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
While correctly used, it looks suspect and is slightly less efficient
because the string is scanned twice for its terminating nul byte.
PR-URL: https://github.com/libuv/libuv/pull/2065
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Libuv had coverage for the AF_INET6 path but not the AF_INET path.
Now it does.
PR-URL: https://github.com/libuv/libuv/pull/2065
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Right now, docs don't make it clear when exactly does it become okay to
free memory belonging to `uv_handle_t`. It's only stated that
`uv_close` must be called before freeing the memory, which is a source
of confusion for new users: they call `uv_close(handle, NULL)`, then
free the memory (see e.g. #2078, https://stackoverflow.com/q/25615340).
PR-URL: https://github.com/libuv/libuv/pull/2087
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Origin README about build command is not suited for current code.
1. gyp_uv.py generated uv.xcodeproj file in directory 'out' instead of
repository root directory
2. xcode build target params use '-alltargets' instead of '-target All'.
PR-URL: https://github.com/libuv/libuv/pull/2095
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Valgrind will emit the following error on a system where `int` is 32
bits:
==21616== Syscall param epoll_ctl(event) points to uninitialised byte(s)
==21616== at 0x693E06A: epoll_ctl (syscall-template.S:84)
==21616== by 0x529F35B: uv__io_poll (in .../libuv/libuv.so)
==21616== by 0x528AE62: uv_run (in .../libuv/libuv.so)
[...]
==21616== Address 0x1ffeffc8ec is on thread 1's stack
==21616== in frame #1, created by uv__io_poll (???:)
We only initialise e.events and e.data.fd, meaning half of
e.data (the 32 bits not covered by the 4-byte `fd`) is
uninitialised.
PR-URL: https://github.com/libuv/libuv/pull/1996
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Added UV_PROCESS_WINDOWS_HIDE_CONSOLE and
UV_PROCESS_WINDOWS_HIDE_GUI for specifying if console or GUI
subprocess windows are to be hidden.
Refs: https://github.com/nodejs/node/pull/24034
PR-URL: https://github.com/libuv/libuv/pull/2073
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
The length calculation of the title string was
performed outside of the mutex, causing data corruption
in heavily contended scenarios. Move the length
computation to within the mutex block
Fixes: https://github.com/libuv/libuv/issues/2063
PR-URL: https://github.com/libuv/libuv/pull/2069
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Libuv loaded and unloaded the Core Services and Application Services for
every call to uv_set_process_title().
Change that to load them on the first call to uv_set_process_title() and
delay unloading until libuv is unloaded.
Speeds up process_title_threadsafe by about 10x on my system.
PR-URL: https://github.com/libuv/libuv/pull/2064
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
On Windows rename operation can fail randomly in presence of antivirus
or indexing software. Make `uv_fs_rename` retry up to four times with
250ms delay between attempts before giving up.
PR-URL: https://github.com/libuv/libuv/pull/1981
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
On some localized Windows 10 machines FormatMessage can fail with
ERROR_RESOURCE_TYPE_NOT_FOUND when trying to generate dlopen error
message. This adds support for this corner case.
PR-URL: https://github.com/libuv/libuv/pull/2052
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Encode domain names before passing them on to the libc resolver.
Some getaddrinfo() implementations support IDNA 2008, some only
IDNA 2003 and some don't support i18n domain names at all.
This is a potential security issue because it means a domain name
might resolve differently depending on the system that libuv is
running on.
Fixes: https://github.com/libuv/libuv/issues/2028
PR-URL: https://github.com/libuv/libuv/pull/2046
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
The test runner inserted a 250 ms delay to give helper processes time to
settle. That's intrinsically race-y and caused tests to intermittently
fail on platforms like AIX.
Instead of a fixed delay, pass a file descriptor to the helper process
and wait until it closes the descriptor. That way we know for sure the
process has started.
Incidentally, this change reduces the running time of the test suite
from 112 to 26 seconds on my machine.
Fixes: https://github.com/libuv/libuv/issues/2041
PR-URL: https://github.com/libuv/libuv/pull/2056
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
execvp() is not async-signal-safe, execve() is.
PR-URL: https://github.com/libuv/libuv/pull/2056
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
getenv() and atoi() are not safe to call between fork() and execve()
so call them before forking.
PR-URL: https://github.com/libuv/libuv/pull/2056
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
In some situations console read callback would return 0 bytes read.
According to documentation this means EAGAIN or EWOULDBLOCK, which is
not the case in any of the situations that currently happen.
This removes those zero-size callbacks.
Fixes: https://github.com/libuv/libuv/issues/2012
PR-URL: https://github.com/libuv/libuv/pull/2014
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Since SIGWINCH is being defined with a value above the existing NSIG,
redefine NSIG on WIN32.
PR-URL: https://github.com/libuv/libuv/pull/2032
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Use `setproctitle()` in `FreeBSD` as in the other `BSD` flavours.
Move `uv_setup_args()`, `uv_set_process_title()` and `uv_get_process_title()` to
`bsd-proctitle.c` so it's used by the supported BSDs.
PR-URL: https://github.com/libuv/libuv/pull/2042
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
It was introduced in commit abdc3efffe ("unix: add uv__dup()") from
January 2012 to break ground for commit e34dc13496 ("unix: implement
uv_import() and uv_export()").
Those APIs were removed not much later but I forgot to remove the
helper function as well. Better late than never, eh?
PR-URL: https://github.com/libuv/libuv/pull/2043
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
`malloc(0)` and `realloc(p, 0)` can either return NULL or a unique
pointer. Make our custom allocator return NULL for consistency across
platforms and libcs.
PR-URL: https://github.com/libuv/libuv/pull/2038
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
As a requested style nit, remove two unnecessary line breaks.
PR-URL: https://github.com/libuv/libuv/pull/2039
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
This commit does a few things to make the function more
consistent across platforms:
- Initialize the output parameters before everything else.
- Return early if there are no interfaces instead of performing
zero-sized allocations.
- Add a missing memory deallocation.
Refs: https://github.com/libuv/libuv/pull/2035
PR-URL: https://github.com/libuv/libuv/pull/2039
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
