Do not rely on the udp_receive_buffer field from IsolateData as a buffer for
reading data in the recvfrom call.
Bug:
Change-Id: I43d19f624fd2a406429cc5387bd536524472b4f7
Reviewed-on: https://dart-review.googlesource.com/10212
Reviewed-by: Zach Anderson <zra@google.com>
If an Isolate touches the 'stdio' getter, a _NativeSocket with
attached finalizer is created for it. Previously, when such an
Isolate exited, the finalizer would close the underlying
file descriptor. This CL changes the finalizer for stdin such
that the native objects will be cleaned up, but the underlying
file descriptor will not be closed. The underlying file
descriptor will now only be closed if the stdin stream
subscription is explicitly canceled.
Accessing the stdin getter after the stream is explicitly
canceled will result in a FileSystemException.
See also: https://github.com/dart-lang/test/issues/583fixes#29229R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2791423002 .
Revert "Pulled a significant portion of Socket implementation into BaseSocket in order to prepare for the synchronous socket impementations which will also use these common methods."
This reverts commit 0422920142.
Revert "Updated incorrect call to Write in process_win.cc"
This reverts commit 9e1435148b.
Revert "Fixed incorrect call to Write from process_win.cc"
This reverts commit 11dcab2bed3c9ec8ec76bc200206ac202a4a5681.
Fixed incorrect call to Write from process_win.cc
BUG=
Review-Url: https://codereview.chromium.org/2791163004 .
The finalizer sends the "close" message to the EventHandler for the
file descriptor in the _NativeSocket's native field. To avoid races and
spurious messages, this CL stores a pointer to a wrapper object in the
native field instead of the file descriptor. All messsages about the
_NativeSocket sent to the EventHandler use the wrapper object instead of
the file descriptor. When the EventHandler closes the file, the file
descriptor in the wrapper object is set to -1 so that the finalizer will
instead do nothing.
On Windows, there is another level of indirection since the OS HANDLEs
were already wrapped in various kinds of Handle objects. As an additional
complication, ClientSocket close on Windows is asynchronous, so the
EventHandler may shutdown before all of the ClientSocket Handles can be
destroyed.
related #27898, #28081R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2760293002 .
The struct sockaddr containing the remote address was being reported
rather than the actual sin_addr / sin6_addr fields. Use the ToTypedData
utility function to return the real address bytes as a dart list. Before
this fix all remote addresses would be reported (on Linux) as 2.0.x.y where
2.0 means IPv4 and x.y are the remote port in big endian, i.e. the first
four bytes of struct sockaddr.
R=rmacnak@google.com
BUG=
Review-Url: https://codereview.chromium.org/2665973003 .
The way runtime/platform/hashmap.h:HashMap was implemented so far did not allow
deleting elements while iterating over the map. If one iterated like this
HashMap::Entry* cursor = map.Start();
while (cursor != NULL) {
if (cond) {
map.Remove(cursor->key, cursor->hash);
}
cursor = map.Next(cursor);
}
Then the iteration `cursor` will skip elements. This is due to the fact that
`HashMap::Remove()` is left-rotating elements in certain cases and
`HashMap::Next()` will unconditionally advance to the next position in the
backing store.
PROBLEM IS: There was existing code which did remove elements while iterating
over a HashMap.
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2533303005 .
The following happened:
A listening socket (ipv4, first-port) was created. Afterwards another
listening socket (ipv6, 0) is being created. We look up in the hashmap
if there is already a listening socket on port `0` (which is never the case).
So we create a new socket, the OS assigns the socket a random port
(which just happens to be `first-port` as well). Then we insert a new OSSocket
entry into the hashmap with key `first-port` (and set its `next` field to NULL).
This will simply override the existing entry.
During shutdown we loop over all (fd, OSSocket) pairs and try to remove
`OSSocket` from the port->socket map (via the linked `next` list). We cannot
find the `OSSocket` which we accidentally droped earlier, so we dereference
`0->next` and hit a SEGFAULT.
What should've happend is to correctly link the `OSSocket`s via the next field.
Fixes#27847R=asiva@google.com, fschneider@google.com
Review URL: https://codereview.chromium.org/2540013002 .
Fix some misspelled flags.
Remove some non-existent flags.
Fix --short_socket_read and --short_socket_write flags used in IO tests.
Running with --ignore-unrecognized-flags is still on because some flags are only visible
in DEBUG mode.
BUG=
R=asiva@google.com
Review URL: https://codereview.chromium.org/2247733005 .
Previously, Socket::ListInterfaces failed to set the os_error out
parameter causing a crash in the caller. This change sets an error here.
I've also added NetworkInterface.listSupported, which returns false on
Android, and true everywhere else. ifaddrs.h continues not to exist in
the NDK, so in order to support NetworkInterface.list, we'd have to
reimplement it, or find a suitable reimplementation somewhere.
related #26329R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org/1916223003 .
Previously we would compile in implementaitions of native calls for
IO functions that would never be used. This CL provides implementations
that throw a Dart exception if they're called by mistake. It also uses
a DART_IO_DISABLED preprocessor define to clean up the build files and
check that we're not including code we shouldn't.
R=iposva@google.com, johnmccutchan@google.com
Review URL: https://codereview.chromium.org/1839463002 .
Siva Annamalai