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 .
Install a signal handler in the standalone VM that dumps a backtrace
similar to what we already do on assertion failures.
For now only Linux and MacOS are supported.
BUG=
R=asiva@google.com
Review URL: https://codereview.chromium.org/2514113002 .
- Remove CheckConnect.
- Enable NODELAY.
- Add testSimpleReadWriteClose to hello_fuchsia_test.
Add stub implementation of OS::MaxRSS so Observatory can load without crashing the target VM.
R=asiva@google.com
Review URL: https://codereview.chromium.org/2523133002 .
Print snapshot sizes when generating an AOT snapshot from gen_snapshot (e.g., Flutter).
Remove some unnecessary symbols.
Use named constants for exit codes.
Use Log::PrintErr instead of fprintf(stderr) so we see error messages in adb logcat.
R=asiva@google.com
Review URL: https://codereview.chromium.org/2517683002 .
The file size is not rounded up after the isolate snapshot if there are no rodata/instruction pieces. The other OS's use mmap instead of read, which is apparently okay with over-reading the file.
Fixes#27786R=asiva@google.com
Review URL: https://codereview.chromium.org/2521883002 .
Calling out to python from GN to process gypi files is relatively
expensive with a 20-45ms fixed overhead for setup/teardown regardless
of what the script does. This makes runtime/vm/BUILD.gn take 1-1.5s
(per toolchain) to run as the template for libraries expands
out to 25 calls to gypi_to_gn.py, even though the actual time spent
processing the gypi files is negligible.
This replaces those repeated calls to gypi_to_gn.py with a call to a
custom script that process all of the gypi files needed for runtime/vm
and places the results into a single scope which can then be read from
in the template and replaces a few other scattered calls to
gypi_to_gn.py with a smaller number of calls that process multiple
gypi files and place the results into a single scope.
The end result is processing all of dart's GN files in a fuchsia build
takes ~250ms instead of >3 seconds.
R=zra@google.com
Review URL: https://codereview.chromium.org/2472813002 .
Committed: ad86d6ed26
I'm starting to try to track down the hang in socket_test in
a call to read() on Mac. We weren't checking that the calls
to set fds non-blocking were successful, so I'll start with
adding code to do that.
This CL also fixes the GN arm android build.
R=asiva@google.com
Review URL: https://codereview.chromium.org/2495003003 .
Appears to break builds with errors like:
ninja -C xcodebuild/ProductX64 runtime
ninja: Entering directory `xcodebuild/ProductX64'
ninja: error: '../../runtime/vm/async_patch.dart', needed by 'obj/runtime/vm/concatenate_async_patch.inputdeps.stamp', missing and no known rule to make it
BUILD FAILED
step returned non-zero exit code: 1
@@@STEP_FAILURE@@@
This reverts commit ad86d6ed26.
BUG=
Review URL: https://codereview.chromium.org/2492053002 .
Calling out to python from GN to process gypi files is relatively
expensive with a 20-45ms fixed overhead for setup/teardown regardless
of what the script does. This makes runtime/vm/BUILD.gn take 1-1.5s
(per toolchain) to run as the template for libraries expands
out to 25 calls to gypi_to_gn.py, even though the actual time spent
processing the gypi files is negligible.
This replaces those repeated calls to gypi_to_gn.py with a call to a
custom script that process all of the gypi files needed for runtime/vm
and places the results into a single scope which can then be read from
in the template and replaces a few other scattered calls to
gypi_to_gn.py with a smaller number of calls that process multiple
gypi files and place the results into a single scope.
The end result is processing all of dart's GN files in a fuchsia build
takes ~250ms instead of >3 seconds.
R=zra@google.com
Review URL: https://codereview.chromium.org/2472813002 .
