Calling quit() from d8 will call exit(), which will run static destructors. If
context_mutex_ is statically allocated, pthread_mutex_destroy will be called.
When running d8 in "isolates" mode, another thread may be running. If it calls
CreateEvaluationContext, it will lock the context_mutex_. If the mutex is
destroyed while it is locked, it will return an error.
This CL changes the Mutex to a LazyMutex, which will leak instead of being
destroyed.
BUG=v8:4279
R=jarin@chromium.orgR=machenbach@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1240553003
Cr-Commit-Position: refs/heads/master@{#29709}
Note: the previous try was reverted for occasional flaky tests. This continued
after the revert, and should be fixed by
https://codereview.chromium.org/1226143003.
Previously, the serialization code would call Externalize for every transferred
ArrayBuffer or SharedArrayBuffer, but that function can only be called once. If
the buffer is already externalized, we should call GetContents instead.
Also fix use-after-free bug when transferring ArrayBuffers. The transferred
ArrayBuffer must be internalized in the new isolate, or be managed by the
Shell. The current code gives it to the isolate externalized and frees it
immediately afterward when the SerializationData object is destroyed.
BUG=chromium:497295
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1223813008
Cr-Commit-Position: refs/heads/master@{#29658}
* Fix embarrassing bug in DeserializeValue, using a static buffer in
multithreaded code.
* Fix thread leak when Worker.terminate() is not called.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1226143003
Cr-Commit-Position: refs/heads/master@{#29626}
When quit() is called, d8 shell exits without cleanup. If a worker is running,
it might be holding the context_mutex_, which if destroyed will DCHECK.
BUG=4279
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1231473002
Cr-Commit-Position: refs/heads/master@{#29557}
This one occurred when serializing an object. When the property getter threw an
exception, that value was skipped, but the property count wasn't updated. The
deserializer then tried to deserialize the wrong value.
BUG=chromium:506549
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1220193004
Cr-Commit-Position: refs/heads/master@{#29541}
Reason for revert:
[Sheriff] Test hangs sometimes and times out flakily. E.g.: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosse3/builds/4551/steps/Check%20%28flakes%29/logs/d8-worker-sharedarray..
Original issue's description:
> Fix bug when transferring SharedArrayBuffer to multiple Workers.
>
> Previously, the serialization code would call Externalize for every transferred
> ArrayBuffer or SharedArrayBuffer, but that function can only be called once. If
> the buffer is already externalized, we should call GetContents instead.
>
> Also fix use-after-free bug when transferring ArrayBuffers. The transferred
> ArrayBuffer must be internalized in the new isolate, or be managed by the
> Shell. The current code gives it to the isolate externalized and frees it
> immediately afterward when the SerializationData object is destroyed.
>
> BUG=chromium:497295
> R=jarin@chromium.org
> LOG=n
>
> Committed: https://crrev.com/dd7962bf7838f8379ba776ee6b7b0e4d3bec2140
> Cr-Commit-Position: refs/heads/master@{#29499}
TBR=jarin@chromium.org,jochen@chromium.org,binji@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:497295
Review URL: https://codereview.chromium.org/1224843008
Cr-Commit-Position: refs/heads/master@{#29506}
Previously, the serialization code would call Externalize for every transferred
ArrayBuffer or SharedArrayBuffer, but that function can only be called once. If
the buffer is already externalized, we should call GetContents instead.
Also fix use-after-free bug when transferring ArrayBuffers. The transferred
ArrayBuffer must be internalized in the new isolate, or be managed by the
Shell. The current code gives it to the isolate externalized and frees it
immediately afterward when the SerializationData object is destroyed.
BUG=chromium:497295
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1215233004
Cr-Commit-Position: refs/heads/master@{#29499}
This is more consistent with the DOM API, and is clearer w.r.t. which values
are available in the lexical environment of the Worker.
BUG=chromium:497295
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1218553004
Cr-Commit-Position: refs/heads/master@{#29426}
v8::Internal::List will DCHECK when indexing out of the array, even if just to
get the address, and the value is never used. So this construct will fail:
memcpy(p, &data[0], length);
When data is empty and length is 0.
BUG=chromium:505778
R=mstarzinger@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1216853003
Cr-Commit-Position: refs/heads/master@{#29388}
Dumb typo introduced in refs/heads/master@{#29306}. I thought I was turning on
report_exceptions in Shell::ExecuteString, but instead I turned on print_result
(which assumes an interactive debugger and a HandleScope for the
utility_context_).
BUG=chromium:504727,chromium:504728
R=mstarzinger@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1219563002
Cr-Commit-Position: refs/heads/master@{#29350}
The issue is that Worker.prototype.terminate was deleting the C++ Worker
object, and then Worker.prototype.getMessage was trying to read messages from
the queue.
The simplest solution is to keep workers in a zombie state when they have been
terminated. They won't be reaped until Shell::CleanupWorkers is called.
I've also fixed some threading issues with Workers:
* Workers can be created by another Worker, so the Shell::workers_ variable
must be protected by a mutex.
* An individual Worker can typically only be accessed by the isolate that
created it, but the main thread can always terminate it, so the Worker::state_
must be accessed in a thread-safe way.
BUG=chromium:504136
R=jochen@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1208733002
Cr-Commit-Position: refs/heads/master@{#29306}
Shell::SerializeValue was using a HandleScope, but was also storing Handles in
an ObjectList. The ObjectList handles would persist after the function had
returned, but will have already been destroyed by the HandleScope, so there is
a use-after-free.
This change removes the HandleScope in Shell::SerializeValue and relies on the
caller's HandleScope.
BUG=chromium:503968
R=jochen@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1211433003
Cr-Commit-Position: refs/heads/master@{#29265}
This API closely matches the Worker API. The differences:
1) The argument to the Worker constructor is a function to run, not a script.
2) Receiving a message from a worker is a synchronous API (as there is no event
loop).
The serialization done here is not robust as the real DOM implementation. For
example, recursive data structures or otherwise duplicated objects are not
allowed.
BUG=chromium:497295
LOG=n
Review URL: https://codereview.chromium.org/1192923002
Cr-Commit-Position: refs/heads/master@{#29195}
Reason for revert:
Fails on V8 Linux - isolates (http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20isolates/builds/4128)
Original issue's description:
> Add d8 API for spawning function on a new thread (Second try)
>
> This API closely matches the Worker API. The differences:
>
> 1) The argument to the Worker constructor is a function to run, not a script.
> 2) Receiving a message from a worker is a synchronous API (as there is no event
> loop).
>
> The serialization done here is not robust as the real DOM implementation. For
> example, recursive data structures or otherwise duplicated objects are not
> allowed.
>
> BUG=chromium:497295
> R=jochen@chromium.org
> LOG=n
>
> Review URL: https://codereview.chromium.org/1185643004
>
> Cr-Commit-Position: refs/heads/master@{#29126}
>
> Committed: https://crrev.com/ec2eaf712ecee6b4891c0458f2397e04a1f9b339
> Cr-Commit-Position: refs/heads/master@{#29158}
TBR=jochen@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:497295
Review URL: https://codereview.chromium.org/1191373005
Cr-Commit-Position: refs/heads/master@{#29161}
This API closely matches the Worker API. The differences:
1) The argument to the Worker constructor is a function to run, not a script.
2) Receiving a message from a worker is a synchronous API (as there is no event
loop).
The serialization done here is not robust as the real DOM implementation. For
example, recursive data structures or otherwise duplicated objects are not
allowed.
BUG=chromium:497295
R=jochen@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1185643004
Cr-Commit-Position: refs/heads/master@{#29126}
Review URL: https://codereview.chromium.org/1195613003
Cr-Commit-Position: refs/heads/master@{#29158}
This API closely matches the Worker API. The differences:
1) The argument to the Worker constructor is a function to run, not a script.
2) Receiving a message from a worker is a synchronous API (as there is no event
loop).
The serialization done here is not robust as the real DOM implementation. For
example, recursive data structures or otherwise duplicated objects are not
allowed.
BUG=none
R=jochen@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1185643004
Cr-Commit-Position: refs/heads/master@{#29126}
We shouldn't have shared state between isolates by default. The embedder
is free to pass the same allocator to all isolates it creates.
BUG=none
R=dcarney@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1116633002
Cr-Commit-Position: refs/heads/master@{#28127}
Currently only the Win64 bots report this warnings, which adds quite
some overhead to the development process. With this flag we also get
compiler warnings about implicit 64bit to 32bit truncations when
building with clang on Linux/x64 and Mac/x64.
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/1111733002
Cr-Commit-Position: refs/heads/master@{#28093}
The embedder can control how many threads it wants to use via the
v8::Platform implementation. V8 internally doesn't spin up threads
anymore. If the embedder doesn't want to use any threads at all, it's
v8::Platform implementation must either run the background jobs on
the foreground thread, or the embedder should specify --predictable
BUG=none
R=yangguo@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1064723005
Cr-Commit-Position: refs/heads/master@{#27833}
Some native counters (e.g. KeyedLoadGenericSlow) are referenced from stubs that are generated very early in the Isolate lifecycle before v8::Isolate::New returns. Thus counter lookup callback also needs to be installed early prior to v8::internal::Isolate::Init call. Otherwise assembler will just assume that the counter is not enabled and produce no code from IncrementCounter - because address of the counter is not yet available.
Histogram related callbacks are moved for consistency to make them able to collect samples which occur at isolate initialization time.
BUG=
Review URL: https://codereview.chromium.org/1010233002
Cr-Commit-Position: refs/heads/master@{#27262}
