About this CL:
The only purpose of `if (fork() == 0) exit(0)` is to wake up
a thread in the parent process which might be blocked on `wait()`.
There is no need to run atexit() handlers in the `fork()`ed child.
This is a *workaround attempt* for a deadlocked `free()` call inside the
processing of atexit handlers in glibc.
(Side note: There might be better ways of notifying the thread, like sending a
signal to the particular pthread with `pthread_kill` which would make the
`wait()` syscall be interrupted.)
About the issue:
It is still unclear why, in this particular case, the tcmalloc locks should
be hold during the `exit()` call:
* via a static initializer tcmalloc uses
`pthread_atfork(before=ObtainAllLocks(),
after_parent=ReleaseAllLocks(),
after_child=ReleaseAllLocks())`
to register locking & unlocking around `fork()`
* glibc's `fork()` runs the either `after_parent` or `after_child` handlers
(unconditionally) which should free the locks
* the `exit()` call later should be free to malloc/free
The [BUG] describes more in detail how we can hit a tcmalloc deadlock in a
different situation (it's a linux kernel bug).
Namely, if the linux kernel runs OOM during `fork()` and therefore fails to
set the new thread-id. The glibc code hits an assert and tries to allocate
memory before `after_parent`/`after_child` handlers were executed which
deadlocks.
BUG=https://github.com/dart-lang/sdk/issues/28246R=vegorov@google.com
Review-Url: https://codereview.chromium.org/2618723002 .
The analyzer has a stricter patch parser than the VM. Patch files
cannot change signatures of patched members. Specifically, they cannot
change:
- the return type
- a parameter's name
- a parameter to an initializing formal
- an optional parameter's default value
BUG=
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2612043002 .
Now, failing to allocate a buffer for stderr or stdout will generate
an ENOMEM OSError exception.
Also previously, read() returning an error would cause buffers for
stderr and stdout to leak. After this change, they'll be reclaimed.
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2596543002 .
- Adjust fingerprints to be independent of the library's private key, which varies with load order.
- Use usage_counter in AOT inlining decisions if JIT feedback is available.
- Reduce inlining in cold functions.
dart2js product aot snapshot 15841351 -> 14436273 (-8.86%)
R=fschneider@google.com
Review-Url: https://codereview.chromium.org/2562693003 .
Fuchsia host build boilerplate doesn't setup rpath the same way that
the standalone build does, so we pass the flags explicitly when
building dart executables.
Review URL: https://codereview.chromium.org/2552203006 .
To run a script with the Dart->Kernel parser, use the -dfe option:
dart --dfe=runtime/tools/kernel-service.dart --packages=/src/d2/sdk/.packages foo.dart
The front end expects a directory named patched_sdk in the build directory (patched_sdk should be a sibling of the directory that contains the dart executable.)
Warning: using a debug build dart executable is very slow. It takes 2 minutes to run Hello World in a debug build, and about 7 seconds in a release build.
BUG=
R=asiva@google.com
Review URL: https://codereview.chromium.org/2558673002 .
To run a script with the Dart->Kernel parser, use the -dfe option:
dart --dfe=runtime/tools/kernel-service.dart --packages=/src/d2/sdk/.packages foo.dart
The front end expects a directory named patched_sdk in the build directory (patched_sdk should be a sibling of the directory that contains the dart executable.)
Warning: using a debug build dart executable is very slow. It takes 2 minutes to run Hello World in a debug build, and about 7 seconds in a release build.
BUG=
R=asiva@google.com
Review URL: https://codereview.chromium.org/2483373002 .
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 .
Zachary Anderson