This happens in certain build environments such as Jenkins if
some tweaking is not performed in the host system.
PR-URL: https://github.com/libuv/libuv/pull/22
The get_currentexe test requires a canonicalized argv[0] to check
against. Before this commit, it failed when argv[0] contained symbolic
links.
Fixeslibuv/libuv#18.
Fix various typos and spelling mistakes in comments.
Does not affect any code, just changes comments.
PR-URL: https://github.com/libuv/libuv/pull/17
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Fix various typos and spelling mistakes in the documentation
PR-URL: https://github.com/libuv/libuv/pull/17
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Make sure we initialize it after the handle was removed from the pending
queue so that QUEUE_REMOVE doesn't do an invalid write when the process
is closed.
Valgrind output:
==4362== Invalid write of size 8
==4362== at 0x407DB8: uv__process_close (process.c:515)
==4362== by 0x404F94: uv_close (core.c:138)
==4362== by 0x4037C5: main (invalid_write.c:33)
==4362== Address 0xffeffc820 is not stack'd, malloc'd or (recently) free'd
==4362==
==4362== Invalid write of size 8
==4362== at 0x407DC3: uv__process_close (process.c:515)
==4362== by 0x404F94: uv_close (core.c:138)
==4362== by 0x4037C5: main (invalid_write.c:33)
==4362== Address 0xffeffc828 is not stack'd, malloc'd or (recently) free'd
Refs: joyent/libuv/issues/1584
The existing probes, all two of them, cause a great deal of pain for
people trying to build libuv on Linux because of SystemTap's dtrace(1)
utilitity not understanding the -xnolibs flag.
We could hack around that but it's easier to just remove the probes:
they are largely useless and unused while still needing a lot of
supporting infrastructure. This commit removes 200 lines of code
and configuration.
Refs joyent/libuv#1478.
59658a8de7 changed uv_thread_self()
to return uv_thread_t, but uv_thread_t is a thread's HANDLE while
uv_thread_self() returns the current thread's id.
This means that uv_thread_equal() is also broken, as we are
potentially comparing HANDLES to ids.
Changed uv_thread_self() to return the current thread's creation handle.
Fixed small doc issue.
When multiple bufs are specified, overlapped needs to be advanced
manually between each write. Without this, each buf will be written
to the same position (if offset is specified.)
ReadFile() automatically advances, but WriteFile() does not.
uv_interface_addresses was using the linked list pointed to by
the FirstPrefix member of IP_ADAPTER_ADDRESSES in order to compute the
network prefix / network mask.
This was flawed in several ways:
- FirstPrefix can be NULL, and we would crash.
- On Windows Vista and later, the prefix list includes three IP adapter prefixes
for each IP address assigned to the adapter. We were assuming a 1:1 mapping
with the unicast address list.
- Even on Windows versions (i.e. XP) where the prefix list is supposed to have
one and only one element for each unicast address, the order of the two lists
is not guaranteed to be the same.
This fix was inspired and adapted from a commit in the Chromium project:
https://codereview.chromium.org/25167002/diff/6001/net/base/net_util_win.cc
See MSDN article for reference:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366058(v=vs.85).aspx
Excerpt from MSDN below:
In addition, the linked IP_ADAPTER_UNICAST_ADDRESS structures pointed to
by the FirstUnicastAddress member and the linked IP_ADAPTER_PREFIX
structures pointed to by the FirstPrefix member are maintained as separate
internal linked lists by the operating system. As a result, the order of
linked IP_ADAPTER_UNICAST_ADDRESS structures pointed to by the
FirstUnicastAddress member does not have any relationship with the order
of linked IP_ADAPTER_PREFIX structures pointed to by the FirstPrefix member.
On Windows Vista and later, the linked IP_ADAPTER_PREFIX structures pointed to
by the FirstPrefix member include three IP adapter prefixes for each IP address
assigned to the adapter. These include the host IP address prefix, the subnet
IP address prefix, and the subnet broadcast IP address prefix. In addition, for
each adapter there is a multicast address prefix and a broadcast address prefix.
