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: https://github.com/dart-lang/sdk/commit/ad86d6ed26e3b6eeeaa96b654881a49c4b04a561
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 .
By configuring the same list twice, this function call doesn't do
anything. This mechanism is also no longer useful and is slowly being
wound down.
(That API is remnant of when we had RC4. Both RC4 and CBC mode ciphers
are horribly broken. For a time, whether you preferred RC4 or CBC varied
depending on what version you had since the CBC mode ciphers are
increasibly broken the further back you go. Now RC4 is completely gone
anyway, so it's not useful. Regardless, the way Dart uses it never did
anything.)
BUG=none
R=whesse@google.com
Review URL: https://codereview.chromium.org/2470553002 .
Martin Kustermann