v8/test/inspector/inspector-test.cc

907 lines
36 KiB
C++
Raw Normal View History

// Copyright 2016 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
#if !defined(_WIN32) && !defined(_WIN64)
#include <unistd.h>
#endif // !defined(_WIN32) && !defined(_WIN64)
#include <locale.h>
#include <string>
#include <vector>
#include "include/libplatform/libplatform.h"
#include "include/v8-exception.h"
Reland "[include] Split out v8.h" This is a reland of d1b27019d3bf86360ea838c317f8505fac6d3a7e Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
2021-08-23 13:01:06 +00:00
#include "include/v8-initialization.h"
#include "include/v8-local-handle.h"
#include "include/v8-snapshot.h"
#include "src/base/platform/platform.h"
#include "src/base/small-vector.h"
#include "src/flags/flags.h"
#include "src/utils/utils.h"
#include "test/inspector/frontend-channel.h"
#include "test/inspector/isolate-data.h"
#include "test/inspector/task-runner.h"
#include "test/inspector/tasks.h"
#include "test/inspector/utils.h"
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
namespace v8 {
namespace internal {
extern void DisableEmbeddedBlobRefcounting();
extern void FreeCurrentEmbeddedBlob();
extern v8::StartupData CreateSnapshotDataBlobInternal(
v8::SnapshotCreator::FunctionCodeHandling function_code_handling,
const char* embedded_source, v8::Isolate* isolate);
extern v8::StartupData WarmUpSnapshotDataBlobInternal(
v8::StartupData cold_snapshot_blob, const char* warmup_source);
namespace {
base::SmallVector<TaskRunner*, 2> task_runners;
class UtilsExtension : public InspectorIsolateData::SetupGlobalTask {
public:
~UtilsExtension() override = default;
void Run(v8::Isolate* isolate,
v8::Local<v8::ObjectTemplate> global) override {
v8::Local<v8::ObjectTemplate> utils = v8::ObjectTemplate::New(isolate);
utils->Set(isolate, "print",
v8::FunctionTemplate::New(isolate, &UtilsExtension::Print));
utils->Set(isolate, "quit",
v8::FunctionTemplate::New(isolate, &UtilsExtension::Quit));
utils->Set(isolate, "setlocale",
v8::FunctionTemplate::New(isolate, &UtilsExtension::Setlocale));
utils->Set(isolate, "read",
v8::FunctionTemplate::New(isolate, &UtilsExtension::Read));
utils->Set(isolate, "load",
v8::FunctionTemplate::New(isolate, &UtilsExtension::Load));
utils->Set(isolate, "compileAndRunWithOrigin",
v8::FunctionTemplate::New(
isolate, &UtilsExtension::CompileAndRunWithOrigin));
utils->Set(isolate, "setCurrentTimeMSForTest",
v8::FunctionTemplate::New(
isolate, &UtilsExtension::SetCurrentTimeMSForTest));
utils->Set(isolate, "setMemoryInfoForTest",
v8::FunctionTemplate::New(
isolate, &UtilsExtension::SetMemoryInfoForTest));
utils->Set(isolate, "schedulePauseOnNextStatement",
v8::FunctionTemplate::New(
isolate, &UtilsExtension::SchedulePauseOnNextStatement));
utils->Set(isolate, "cancelPauseOnNextStatement",
v8::FunctionTemplate::New(
isolate, &UtilsExtension::CancelPauseOnNextStatement));
utils->Set(isolate, "setLogConsoleApiMessageCalls",
v8::FunctionTemplate::New(
isolate, &UtilsExtension::SetLogConsoleApiMessageCalls));
utils->Set(isolate, "setAdditionalConsoleApi",
v8::FunctionTemplate::New(
isolate, &UtilsExtension::SetAdditionalConsoleApi));
utils->Set(
isolate, "setLogMaxAsyncCallStackDepthChanged",
v8::FunctionTemplate::New(
isolate, &UtilsExtension::SetLogMaxAsyncCallStackDepthChanged));
utils->Set(isolate, "createContextGroup",
v8::FunctionTemplate::New(isolate,
&UtilsExtension::CreateContextGroup));
utils->Set(
isolate, "createContext",
v8::FunctionTemplate::New(isolate, &UtilsExtension::CreateContext));
utils->Set(
isolate, "resetContextGroup",
v8::FunctionTemplate::New(isolate, &UtilsExtension::ResetContextGroup));
utils->Set(
isolate, "connectSession",
v8::FunctionTemplate::New(isolate, &UtilsExtension::ConnectSession));
utils->Set(
isolate, "disconnectSession",
v8::FunctionTemplate::New(isolate, &UtilsExtension::DisconnectSession));
utils->Set(isolate, "sendMessageToBackend",
v8::FunctionTemplate::New(
isolate, &UtilsExtension::SendMessageToBackend));
utils->Set(isolate, "interruptForMessages",
v8::FunctionTemplate::New(
isolate, &UtilsExtension::InterruptForMessages));
utils->Set(
isolate, "waitForDebugger",
v8::FunctionTemplate::New(isolate, &UtilsExtension::WaitForDebugger));
global->Set(isolate, "utils", utils);
}
static void set_backend_task_runner(TaskRunner* runner) {
backend_runner_ = runner;
}
static void ClearAllSessions() { channels_.clear(); }
private:
static TaskRunner* backend_runner_;
static void Print(const v8::FunctionCallbackInfo<v8::Value>& args) {
for (int i = 0; i < args.Length(); i++) {
v8::HandleScope handle_scope(args.GetIsolate());
if (i != 0) {
printf(" ");
}
// Explicitly catch potential exceptions in toString().
v8::TryCatch try_catch(args.GetIsolate());
v8::Local<v8::Value> arg = args[i];
v8::Local<v8::String> str_obj;
if (arg->IsSymbol()) {
arg = v8::Local<v8::Symbol>::Cast(arg)->Description(args.GetIsolate());
}
if (!arg->ToString(args.GetIsolate()->GetCurrentContext())
.ToLocal(&str_obj)) {
try_catch.ReThrow();
return;
}
v8::String::Utf8Value str(args.GetIsolate(), str_obj);
int n =
static_cast<int>(fwrite(*str, sizeof(**str), str.length(), stdout));
if (n != str.length()) {
FATAL("Error in fwrite\n");
}
}
printf("\n");
fflush(stdout);
}
static void Quit(const v8::FunctionCallbackInfo<v8::Value>& args) {
fflush(stdout);
fflush(stderr);
// Only terminate, so not join the threads here, since joining concurrently
// from multiple threads can be undefined behaviour (see pthread_join).
for (TaskRunner* task_runner : task_runners) task_runner->Terminate();
}
static void Setlocale(const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsString()) {
FATAL("Internal error: setlocale get one string argument.");
}
v8::String::Utf8Value str(args.GetIsolate(), args[1]);
setlocale(LC_NUMERIC, *str);
}
static bool ReadFile(v8::Isolate* isolate, v8::Local<v8::Value> name,
std::string* chars) {
v8::String::Utf8Value str(isolate, name);
bool exists = false;
std::string filename(*str, str.length());
*chars = v8::internal::ReadFile(filename.c_str(), &exists);
if (!exists) {
isolate->ThrowError("Error reading file");
return false;
}
return true;
}
static void Read(const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsString()) {
FATAL("Internal error: read gets one string argument.");
}
std::string chars;
v8::Isolate* isolate = args.GetIsolate();
if (ReadFile(isolate, args[0], &chars)) {
args.GetReturnValue().Set(ToV8String(isolate, chars));
}
}
static void Load(const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsString()) {
FATAL("Internal error: load gets one string argument.");
}
std::string chars;
v8::Isolate* isolate = args.GetIsolate();
v8::Local<v8::Context> context = isolate->GetCurrentContext();
InspectorIsolateData* data = InspectorIsolateData::FromContext(context);
int context_group_id = data->GetContextGroupId(context);
if (ReadFile(isolate, args[0], &chars)) {
ExecuteStringTask(chars, context_group_id).Run(data);
}
}
static void CompileAndRunWithOrigin(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 6 || !args[0]->IsInt32() || !args[1]->IsString() ||
!args[2]->IsString() || !args[3]->IsInt32() || !args[4]->IsInt32() ||
!args[5]->IsBoolean()) {
FATAL(
"Internal error: compileAndRunWithOrigin(context_group_id, source, "
"name, line, column, is_module).");
}
backend_runner_->Append(std::make_unique<ExecuteStringTask>(
args.GetIsolate(), args[0].As<v8::Int32>()->Value(),
ToVector(args.GetIsolate(), args[1].As<v8::String>()),
args[2].As<v8::String>(), args[3].As<v8::Int32>(),
args[4].As<v8::Int32>(), args[5].As<v8::Boolean>()));
}
static void SetCurrentTimeMSForTest(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsNumber()) {
FATAL("Internal error: setCurrentTimeMSForTest(time).");
}
backend_runner_->data()->SetCurrentTimeMS(
args[0].As<v8::Number>()->Value());
}
static void SetMemoryInfoForTest(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1) {
FATAL("Internal error: setMemoryInfoForTest(value).");
}
backend_runner_->data()->SetMemoryInfo(args[0]);
}
static void SchedulePauseOnNextStatement(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 3 || !args[0]->IsInt32() || !args[1]->IsString() ||
!args[2]->IsString()) {
FATAL(
"Internal error: schedulePauseOnNextStatement(context_group_id, "
"'reason', 'details').");
}
std::vector<uint16_t> reason =
ToVector(args.GetIsolate(), args[1].As<v8::String>());
std::vector<uint16_t> details =
ToVector(args.GetIsolate(), args[2].As<v8::String>());
int context_group_id = args[0].As<v8::Int32>()->Value();
RunSyncTask(backend_runner_,
[&context_group_id, &reason,
&details](InspectorIsolateData* data) {
data->SchedulePauseOnNextStatement(
context_group_id,
v8_inspector::StringView(reason.data(), reason.size()),
v8_inspector::StringView(details.data(), details.size()));
});
}
static void CancelPauseOnNextStatement(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsInt32()) {
FATAL("Internal error: cancelPauseOnNextStatement(context_group_id).");
}
int context_group_id = args[0].As<v8::Int32>()->Value();
RunSyncTask(backend_runner_,
[&context_group_id](InspectorIsolateData* data) {
data->CancelPauseOnNextStatement(context_group_id);
});
}
static void SetLogConsoleApiMessageCalls(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsBoolean()) {
FATAL("Internal error: setLogConsoleApiMessageCalls(bool).");
}
backend_runner_->data()->SetLogConsoleApiMessageCalls(
args[0].As<v8::Boolean>()->Value());
}
static void SetLogMaxAsyncCallStackDepthChanged(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsBoolean()) {
FATAL("Internal error: setLogMaxAsyncCallStackDepthChanged(bool).");
}
backend_runner_->data()->SetLogMaxAsyncCallStackDepthChanged(
args[0].As<v8::Boolean>()->Value());
}
static void SetAdditionalConsoleApi(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsString()) {
FATAL("Internal error: SetAdditionalConsoleApi(string).");
}
std::vector<uint16_t> script =
ToVector(args.GetIsolate(), args[0].As<v8::String>());
RunSyncTask(backend_runner_, [&script](InspectorIsolateData* data) {
data->SetAdditionalConsoleApi(
v8_inspector::StringView(script.data(), script.size()));
});
}
static void CreateContextGroup(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 0) {
FATAL("Internal error: createContextGroup().");
}
int context_group_id = 0;
RunSyncTask(backend_runner_,
[&context_group_id](InspectorIsolateData* data) {
context_group_id = data->CreateContextGroup();
});
args.GetReturnValue().Set(
v8::Int32::New(args.GetIsolate(), context_group_id));
}
static void CreateContext(const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 2) {
FATAL("Internal error: createContext(context, name).");
}
int context_group_id = args[0].As<v8::Int32>()->Value();
std::vector<uint16_t> name =
ToVector(args.GetIsolate(), args[1].As<v8::String>());
RunSyncTask(backend_runner_, [&context_group_id,
name](InspectorIsolateData* data) {
CHECK(data->CreateContext(
context_group_id,
v8_inspector::StringView(name.data(), name.size())));
});
}
static void ResetContextGroup(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsInt32()) {
FATAL("Internal error: resetContextGroup(context_group_id).");
}
int context_group_id = args[0].As<v8::Int32>()->Value();
RunSyncTask(backend_runner_,
[&context_group_id](InspectorIsolateData* data) {
data->ResetContextGroup(context_group_id);
});
}
static void ConnectSession(const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 3 || !args[0]->IsInt32() || !args[1]->IsString() ||
!args[2]->IsFunction()) {
FATAL(
"Internal error: connectionSession(context_group_id, state, "
"dispatch).");
}
v8::Local<v8::Context> context = args.GetIsolate()->GetCurrentContext();
FrontendChannelImpl* channel = new FrontendChannelImpl(
InspectorIsolateData::FromContext(context)->task_runner(),
InspectorIsolateData::FromContext(context)->GetContextGroupId(context),
args.GetIsolate(), args[2].As<v8::Function>());
std::vector<uint8_t> state =
ToBytes(args.GetIsolate(), args[1].As<v8::String>());
int context_group_id = args[0].As<v8::Int32>()->Value();
int session_id = 0;
RunSyncTask(backend_runner_, [&context_group_id, &session_id, &channel,
&state](InspectorIsolateData* data) {
session_id = data->ConnectSession(
context_group_id,
v8_inspector::StringView(state.data(), state.size()), channel);
channel->set_session_id(session_id);
});
channels_[session_id].reset(channel);
args.GetReturnValue().Set(v8::Int32::New(args.GetIsolate(), session_id));
}
static void DisconnectSession(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsInt32()) {
FATAL("Internal error: disconnectionSession(session_id).");
}
int session_id = args[0].As<v8::Int32>()->Value();
std::vector<uint8_t> state;
RunSyncTask(backend_runner_,
[&session_id, &state](InspectorIsolateData* data) {
state = data->DisconnectSession(session_id);
});
channels_.erase(session_id);
args.GetReturnValue().Set(ToV8String(args.GetIsolate(), state));
}
static void SendMessageToBackend(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 2 || !args[0]->IsInt32() || !args[1]->IsString()) {
FATAL("Internal error: sendMessageToBackend(session_id, message).");
}
backend_runner_->Append(std::make_unique<SendMessageToBackendTask>(
args[0].As<v8::Int32>()->Value(),
ToVector(args.GetIsolate(), args[1].As<v8::String>())));
}
static void InterruptForMessages(
const v8::FunctionCallbackInfo<v8::Value>& args) {
backend_runner_->InterruptForMessages();
}
static void WaitForDebugger(const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 2 || !args[0]->IsInt32() || !args[1]->IsFunction()) {
FATAL("Internal error: waitForDebugger(context_group_id, callback).");
}
int context_group_id = args[0].As<v8::Int32>()->Value();
RunSimpleAsyncTask(
backend_runner_,
[context_group_id](InspectorIsolateData* data) {
data->WaitForDebugger(context_group_id);
},
args[1].As<v8::Function>());
}
static std::map<int, std::unique_ptr<FrontendChannelImpl>> channels_;
};
TaskRunner* UtilsExtension::backend_runner_ = nullptr;
std::map<int, std::unique_ptr<FrontendChannelImpl>> UtilsExtension::channels_;
bool StrictAccessCheck(v8::Local<v8::Context> accessing_context,
v8::Local<v8::Object> accessed_object,
v8::Local<v8::Value> data) {
CHECK(accessing_context.IsEmpty());
return accessing_context.IsEmpty();
}
class ConsoleExtension : public InspectorIsolateData::SetupGlobalTask {
public:
~ConsoleExtension() override = default;
void Run(v8::Isolate* isolate,
v8::Local<v8::ObjectTemplate> global) override {
v8::Local<v8::String> name =
v8::String::NewFromUtf8Literal(isolate, "console");
global->SetAccessor(name, &ConsoleGetterCallback, nullptr, {}, v8::DEFAULT,
v8::DontEnum);
}
private:
static void ConsoleGetterCallback(
v8::Local<v8::String>, const v8::PropertyCallbackInfo<v8::Value>& info) {
v8::Isolate* isolate = info.GetIsolate();
v8::HandleScope scope(isolate);
v8::Local<v8::Context> context = isolate->GetCurrentContext();
v8::Local<v8::String> name =
v8::String::NewFromUtf8Literal(isolate, "console");
v8::Local<v8::Object> console = context->GetExtrasBindingObject()
->Get(context, name)
.ToLocalChecked()
.As<v8::Object>();
info.GetReturnValue().Set(console);
}
};
class InspectorExtension : public InspectorIsolateData::SetupGlobalTask {
public:
~InspectorExtension() override = default;
void Run(v8::Isolate* isolate,
v8::Local<v8::ObjectTemplate> global) override {
v8::Local<v8::ObjectTemplate> inspector = v8::ObjectTemplate::New(isolate);
inspector->Set(isolate, "fireContextCreated",
v8::FunctionTemplate::New(
isolate, &InspectorExtension::FireContextCreated));
inspector->Set(isolate, "fireContextDestroyed",
v8::FunctionTemplate::New(
isolate, &InspectorExtension::FireContextDestroyed));
inspector->Set(
isolate, "freeContext",
v8::FunctionTemplate::New(isolate, &InspectorExtension::FreeContext));
inspector->Set(isolate, "addInspectedObject",
v8::FunctionTemplate::New(
isolate, &InspectorExtension::AddInspectedObject));
inspector->Set(isolate, "setMaxAsyncTaskStacks",
v8::FunctionTemplate::New(
isolate, &InspectorExtension::SetMaxAsyncTaskStacks));
inspector->Set(
isolate, "dumpAsyncTaskStacksStateForTest",
v8::FunctionTemplate::New(
isolate, &InspectorExtension::DumpAsyncTaskStacksStateForTest));
inspector->Set(
isolate, "breakProgram",
v8::FunctionTemplate::New(isolate, &InspectorExtension::BreakProgram));
inspector->Set(
isolate, "createObjectWithStrictCheck",
v8::FunctionTemplate::New(
isolate, &InspectorExtension::CreateObjectWithStrictCheck));
inspector->Set(isolate, "callWithScheduledBreak",
v8::FunctionTemplate::New(
isolate, &InspectorExtension::CallWithScheduledBreak));
inspector->Set(
isolate, "markObjectAsNotInspectable",
v8::FunctionTemplate::New(
isolate, &InspectorExtension::MarkObjectAsNotInspectable));
inspector->Set(isolate, "createObjectWithAccessor",
v8::FunctionTemplate::New(
isolate, &InspectorExtension::CreateObjectWithAccessor));
inspector->Set(isolate, "storeCurrentStackTrace",
Reland [inspector] introduced stackTraceId and externalAsyncTask API Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. TBR=dgozman@chromium.org,jgruber@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4 Reviewed-on: https://chromium-review.googlesource.com/786274 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49591}
2017-11-22 19:46:33 +00:00
v8::FunctionTemplate::New(
isolate, &InspectorExtension::StoreCurrentStackTrace));
inspector->Set(isolate, "externalAsyncTaskStarted",
Reland [inspector] introduced stackTraceId and externalAsyncTask API Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. TBR=dgozman@chromium.org,jgruber@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4 Reviewed-on: https://chromium-review.googlesource.com/786274 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49591}
2017-11-22 19:46:33 +00:00
v8::FunctionTemplate::New(
isolate, &InspectorExtension::ExternalAsyncTaskStarted));
inspector->Set(
isolate, "externalAsyncTaskFinished",
Reland [inspector] introduced stackTraceId and externalAsyncTask API Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. TBR=dgozman@chromium.org,jgruber@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4 Reviewed-on: https://chromium-review.googlesource.com/786274 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49591}
2017-11-22 19:46:33 +00:00
v8::FunctionTemplate::New(
isolate, &InspectorExtension::ExternalAsyncTaskFinished));
inspector->Set(isolate, "scheduleWithAsyncStack",
v8::FunctionTemplate::New(
isolate, &InspectorExtension::ScheduleWithAsyncStack));
inspector->Set(
isolate, "setAllowCodeGenerationFromStrings",
v8::FunctionTemplate::New(
isolate, &InspectorExtension::SetAllowCodeGenerationFromStrings));
inspector->Set(isolate, "setResourceNamePrefix",
v8::FunctionTemplate::New(
isolate, &InspectorExtension::SetResourceNamePrefix));
inspector->Set(isolate, "newExceptionWithMetaData",
v8::FunctionTemplate::New(
isolate, &InspectorExtension::newExceptionWithMetaData));
inspector->Set(isolate, "callbackForTests",
v8::FunctionTemplate::New(
isolate, &InspectorExtension::CallbackForTests));
[inspector] Fix user-after-free bug around async evaluations This CL fixes a use-after-free bug where we try to access an `InjectedScript` object after it died. This can happen when we transition into JS and back and the context group dies in the mean time (e.g. because of a navigation). Normally we check for this but we missed a call to `Promise#then`. The access that triggers the UaF is when we try to stash away the protocol callback function after returning from `Promise#then`. The callback function is responsible for sending the protocol response back to DevTools containing the result of the evaluation. There are two objects with different lifetimes involved: - InjectedScript: Owns the `EvaluationCallback`. We keep a a reference in case the context group dies. This allows us to cancel any pending evaluate requests. - ProtocolPromiseHandler: Has a reference to `EvaluationCallback`. The handler itself is managed by the V8 GC via `v8::External` and a weak `v8::Global`. When the `ProtocolPromiseHandler` wants use the callback to send a response, it needs to take ownership first. We could invert the ownership but it's preferable for evaluation callbacks to die together with execution contexts and not when the GC feels like it. We fix the UaF by using an `InjectedSript::ContextScope` and reloading the `InjectedScript` after we return from `Promise#then`. Then we can take proper ownership of the callback and use it in case the call failed. R=jarin@chormium.org Fixed: chromium:1366843 Change-Id: I3a68e8609a9681d7343c71f43cc6e67064f41530 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925937 Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/main@{#83506}
2022-09-30 11:47:11 +00:00
inspector->Set(isolate, "runNestedMessageLoop",
v8::FunctionTemplate::New(
isolate, &InspectorExtension::RunNestedMessageLoop));
global->Set(isolate, "inspector", inspector);
}
private:
static void FireContextCreated(
const v8::FunctionCallbackInfo<v8::Value>& args) {
v8::Local<v8::Context> context = args.GetIsolate()->GetCurrentContext();
InspectorIsolateData* data = InspectorIsolateData::FromContext(context);
data->FireContextCreated(context, data->GetContextGroupId(context),
v8_inspector::StringView());
}
static void FireContextDestroyed(
const v8::FunctionCallbackInfo<v8::Value>& args) {
v8::Local<v8::Context> context = args.GetIsolate()->GetCurrentContext();
InspectorIsolateData* data = InspectorIsolateData::FromContext(context);
data->FireContextDestroyed(context);
}
static void FreeContext(const v8::FunctionCallbackInfo<v8::Value>& args) {
v8::Local<v8::Context> context = args.GetIsolate()->GetCurrentContext();
InspectorIsolateData* data = InspectorIsolateData::FromContext(context);
data->FreeContext(context);
}
static void AddInspectedObject(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 2 || !args[0]->IsInt32()) {
FATAL("Internal error: addInspectedObject(session_id, object).");
}
v8::Local<v8::Context> context = args.GetIsolate()->GetCurrentContext();
InspectorIsolateData* data = InspectorIsolateData::FromContext(context);
data->AddInspectedObject(args[0].As<v8::Int32>()->Value(), args[1]);
}
static void SetMaxAsyncTaskStacks(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsInt32()) {
FATAL("Internal error: setMaxAsyncTaskStacks(max).");
}
InspectorIsolateData::FromContext(args.GetIsolate()->GetCurrentContext())
->SetMaxAsyncTaskStacksForTest(args[0].As<v8::Int32>()->Value());
}
static void DumpAsyncTaskStacksStateForTest(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 0) {
FATAL("Internal error: dumpAsyncTaskStacksStateForTest().");
}
InspectorIsolateData::FromContext(args.GetIsolate()->GetCurrentContext())
->DumpAsyncTaskStacksStateForTest();
}
static void BreakProgram(const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 2 || !args[0]->IsString() || !args[1]->IsString()) {
FATAL("Internal error: breakProgram('reason', 'details').");
}
v8::Local<v8::Context> context = args.GetIsolate()->GetCurrentContext();
InspectorIsolateData* data = InspectorIsolateData::FromContext(context);
std::vector<uint16_t> reason =
ToVector(args.GetIsolate(), args[0].As<v8::String>());
v8_inspector::StringView reason_view(reason.data(), reason.size());
std::vector<uint16_t> details =
ToVector(args.GetIsolate(), args[1].As<v8::String>());
v8_inspector::StringView details_view(details.data(), details.size());
data->BreakProgram(data->GetContextGroupId(context), reason_view,
details_view);
}
static void CreateObjectWithStrictCheck(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 0) {
FATAL("Internal error: createObjectWithStrictCheck().");
}
v8::Local<v8::ObjectTemplate> templ =
v8::ObjectTemplate::New(args.GetIsolate());
templ->SetAccessCheckCallback(&StrictAccessCheck);
args.GetReturnValue().Set(
templ->NewInstance(args.GetIsolate()->GetCurrentContext())
.ToLocalChecked());
}
static void CallWithScheduledBreak(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 3 || !args[0]->IsFunction() || !args[1]->IsString() ||
!args[2]->IsString()) {
FATAL("Internal error: callWithScheduledBreak('reason', 'details').");
}
std::vector<uint16_t> reason =
ToVector(args.GetIsolate(), args[1].As<v8::String>());
v8_inspector::StringView reason_view(reason.data(), reason.size());
std::vector<uint16_t> details =
ToVector(args.GetIsolate(), args[2].As<v8::String>());
v8_inspector::StringView details_view(details.data(), details.size());
v8::Local<v8::Context> context = args.GetIsolate()->GetCurrentContext();
InspectorIsolateData* data = InspectorIsolateData::FromContext(context);
int context_group_id = data->GetContextGroupId(context);
data->SchedulePauseOnNextStatement(context_group_id, reason_view,
details_view);
v8::MaybeLocal<v8::Value> result;
result = args[0].As<v8::Function>()->Call(context, context->Global(), 0,
nullptr);
data->CancelPauseOnNextStatement(context_group_id);
}
static void MarkObjectAsNotInspectable(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsObject()) {
FATAL("Internal error: markObjectAsNotInspectable(object).");
}
v8::Local<v8::Object> object = args[0].As<v8::Object>();
v8::Isolate* isolate = args.GetIsolate();
v8::Local<v8::Private> notInspectablePrivate =
v8::Private::ForApi(isolate, ToV8String(isolate, "notInspectable"));
object
->SetPrivate(isolate->GetCurrentContext(), notInspectablePrivate,
v8::True(isolate))
.ToChecked();
}
static void CreateObjectWithAccessor(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 2 || !args[0]->IsString() || !args[1]->IsBoolean()) {
FATAL(
"Internal error: createObjectWithAccessor('accessor name', "
"hasSetter)\n");
}
v8::Isolate* isolate = args.GetIsolate();
v8::Local<v8::ObjectTemplate> templ = v8::ObjectTemplate::New(isolate);
if (args[1].As<v8::Boolean>()->Value()) {
templ->SetAccessor(v8::Local<v8::String>::Cast(args[0]), AccessorGetter,
AccessorSetter);
} else {
templ->SetAccessor(v8::Local<v8::String>::Cast(args[0]), AccessorGetter);
}
args.GetReturnValue().Set(
templ->NewInstance(isolate->GetCurrentContext()).ToLocalChecked());
}
static void AccessorGetter(v8::Local<v8::String> property,
const v8::PropertyCallbackInfo<v8::Value>& info) {
v8::Isolate* isolate = info.GetIsolate();
isolate->ThrowError("Getter is called");
}
static void AccessorSetter(v8::Local<v8::String> property,
v8::Local<v8::Value> value,
const v8::PropertyCallbackInfo<void>& info) {
v8::Isolate* isolate = info.GetIsolate();
isolate->ThrowError("Setter is called");
}
Reland [inspector] introduced stackTraceId and externalAsyncTask API Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. TBR=dgozman@chromium.org,jgruber@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4 Reviewed-on: https://chromium-review.googlesource.com/786274 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49591}
2017-11-22 19:46:33 +00:00
static void StoreCurrentStackTrace(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsString()) {
FATAL("Internal error: storeCurrentStackTrace('description')\n");
Reland [inspector] introduced stackTraceId and externalAsyncTask API Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. TBR=dgozman@chromium.org,jgruber@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4 Reviewed-on: https://chromium-review.googlesource.com/786274 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49591}
2017-11-22 19:46:33 +00:00
}
v8::Isolate* isolate = args.GetIsolate();
v8::Local<v8::Context> context = isolate->GetCurrentContext();
InspectorIsolateData* data = InspectorIsolateData::FromContext(context);
std::vector<uint16_t> description =
ToVector(isolate, args[0].As<v8::String>());
v8_inspector::StringView description_view(description.data(),
description.size());
Reland [inspector] introduced stackTraceId and externalAsyncTask API Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. TBR=dgozman@chromium.org,jgruber@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4 Reviewed-on: https://chromium-review.googlesource.com/786274 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49591}
2017-11-22 19:46:33 +00:00
v8_inspector::V8StackTraceId id =
data->StoreCurrentStackTrace(description_view);
v8::Local<v8::ArrayBuffer> buffer =
v8::ArrayBuffer::New(isolate, sizeof(id));
*static_cast<v8_inspector::V8StackTraceId*>(
buffer->GetBackingStore()->Data()) = id;
Reland [inspector] introduced stackTraceId and externalAsyncTask API Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. TBR=dgozman@chromium.org,jgruber@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4 Reviewed-on: https://chromium-review.googlesource.com/786274 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49591}
2017-11-22 19:46:33 +00:00
args.GetReturnValue().Set(buffer);
}
static void ExternalAsyncTaskStarted(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsArrayBuffer()) {
FATAL("Internal error: externalAsyncTaskStarted(id)\n");
Reland [inspector] introduced stackTraceId and externalAsyncTask API Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. TBR=dgozman@chromium.org,jgruber@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4 Reviewed-on: https://chromium-review.googlesource.com/786274 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49591}
2017-11-22 19:46:33 +00:00
}
v8::Local<v8::Context> context = args.GetIsolate()->GetCurrentContext();
InspectorIsolateData* data = InspectorIsolateData::FromContext(context);
Reland [inspector] introduced stackTraceId and externalAsyncTask API Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. TBR=dgozman@chromium.org,jgruber@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4 Reviewed-on: https://chromium-review.googlesource.com/786274 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49591}
2017-11-22 19:46:33 +00:00
v8_inspector::V8StackTraceId* id =
static_cast<v8_inspector::V8StackTraceId*>(
args[0].As<v8::ArrayBuffer>()->GetBackingStore()->Data());
Reland [inspector] introduced stackTraceId and externalAsyncTask API Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. TBR=dgozman@chromium.org,jgruber@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4 Reviewed-on: https://chromium-review.googlesource.com/786274 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49591}
2017-11-22 19:46:33 +00:00
data->ExternalAsyncTaskStarted(*id);
}
static void ExternalAsyncTaskFinished(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsArrayBuffer()) {
FATAL("Internal error: externalAsyncTaskFinished(id)\n");
Reland [inspector] introduced stackTraceId and externalAsyncTask API Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. TBR=dgozman@chromium.org,jgruber@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4 Reviewed-on: https://chromium-review.googlesource.com/786274 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49591}
2017-11-22 19:46:33 +00:00
}
v8::Local<v8::Context> context = args.GetIsolate()->GetCurrentContext();
InspectorIsolateData* data = InspectorIsolateData::FromContext(context);
Reland [inspector] introduced stackTraceId and externalAsyncTask API Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. TBR=dgozman@chromium.org,jgruber@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4 Reviewed-on: https://chromium-review.googlesource.com/786274 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49591}
2017-11-22 19:46:33 +00:00
v8_inspector::V8StackTraceId* id =
static_cast<v8_inspector::V8StackTraceId*>(
args[0].As<v8::ArrayBuffer>()->GetBackingStore()->Data());
Reland [inspector] introduced stackTraceId and externalAsyncTask API Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. TBR=dgozman@chromium.org,jgruber@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4 Reviewed-on: https://chromium-review.googlesource.com/786274 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49591}
2017-11-22 19:46:33 +00:00
data->ExternalAsyncTaskFinished(*id);
}
static void ScheduleWithAsyncStack(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 3 || !args[0]->IsFunction() || !args[1]->IsString() ||
!args[2]->IsBoolean()) {
FATAL(
"Internal error: scheduleWithAsyncStack(function, 'task-name', "
"with_empty_stack).");
}
v8::Isolate* isolate = args.GetIsolate();
v8::Local<v8::Context> context = isolate->GetCurrentContext();
InspectorIsolateData* data = InspectorIsolateData::FromContext(context);
int context_group_id = data->GetContextGroupId(context);
bool with_empty_stack = args[2].As<v8::Boolean>()->Value();
if (with_empty_stack) context->Exit();
std::vector<uint16_t> task_name =
ToVector(isolate, args[1].As<v8::String>());
v8_inspector::StringView task_name_view(task_name.data(), task_name.size());
RunAsyncTask(
data->task_runner(), task_name_view,
std::make_unique<SetTimeoutTask>(
context_group_id, isolate, v8::Local<v8::Function>::Cast(args[0])));
if (with_empty_stack) context->Enter();
}
static void SetAllowCodeGenerationFromStrings(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsBoolean()) {
FATAL("Internal error: setAllowCodeGenerationFromStrings(allow).");
}
args.GetIsolate()->GetCurrentContext()->AllowCodeGenerationFromStrings(
args[0].As<v8::Boolean>()->Value());
}
static void SetResourceNamePrefix(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsString()) {
FATAL("Internal error: setResourceNamePrefix('prefix').");
}
v8::Isolate* isolate = args.GetIsolate();
v8::Local<v8::Context> context = isolate->GetCurrentContext();
InspectorIsolateData* data = InspectorIsolateData::FromContext(context);
data->SetResourceNamePrefix(v8::Local<v8::String>::Cast(args[0]));
}
static void newExceptionWithMetaData(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 3 || !args[0]->IsString() || !args[1]->IsString() ||
!args[2]->IsString()) {
FATAL(
"Internal error: newExceptionWithMetaData('message', 'key', "
"'value').");
}
v8::Isolate* isolate = args.GetIsolate();
v8::Local<v8::Context> context = isolate->GetCurrentContext();
InspectorIsolateData* data = InspectorIsolateData::FromContext(context);
auto error = v8::Exception::Error(args[0].As<v8::String>());
CHECK(data->AssociateExceptionData(error, args[1].As<v8::String>(),
args[2].As<v8::String>()));
args.GetReturnValue().Set(error);
}
static void CallbackForTests(
const v8::FunctionCallbackInfo<v8::Value>& args) {
if (args.Length() != 1 || !args[0]->IsFunction()) {
FATAL("Internal error: callbackForTests(function).");
}
v8::Isolate* isolate = args.GetIsolate();
v8::Local<v8::Context> context = isolate->GetCurrentContext();
v8::Local<v8::Function> callback = v8::Local<v8::Function>::Cast(args[0]);
v8::MaybeLocal<v8::Value> result =
callback->Call(context, v8::Undefined(isolate), 0, nullptr);
args.GetReturnValue().Set(result.ToLocalChecked());
}
[inspector] Fix user-after-free bug around async evaluations This CL fixes a use-after-free bug where we try to access an `InjectedScript` object after it died. This can happen when we transition into JS and back and the context group dies in the mean time (e.g. because of a navigation). Normally we check for this but we missed a call to `Promise#then`. The access that triggers the UaF is when we try to stash away the protocol callback function after returning from `Promise#then`. The callback function is responsible for sending the protocol response back to DevTools containing the result of the evaluation. There are two objects with different lifetimes involved: - InjectedScript: Owns the `EvaluationCallback`. We keep a a reference in case the context group dies. This allows us to cancel any pending evaluate requests. - ProtocolPromiseHandler: Has a reference to `EvaluationCallback`. The handler itself is managed by the V8 GC via `v8::External` and a weak `v8::Global`. When the `ProtocolPromiseHandler` wants use the callback to send a response, it needs to take ownership first. We could invert the ownership but it's preferable for evaluation callbacks to die together with execution contexts and not when the GC feels like it. We fix the UaF by using an `InjectedSript::ContextScope` and reloading the `InjectedScript` after we return from `Promise#then`. Then we can take proper ownership of the callback and use it in case the call failed. R=jarin@chormium.org Fixed: chromium:1366843 Change-Id: I3a68e8609a9681d7343c71f43cc6e67064f41530 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925937 Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/main@{#83506}
2022-09-30 11:47:11 +00:00
static void RunNestedMessageLoop(
const v8::FunctionCallbackInfo<v8::Value>& args) {
v8::Isolate* isolate = args.GetIsolate();
v8::Local<v8::Context> context = isolate->GetCurrentContext();
InspectorIsolateData* data = InspectorIsolateData::FromContext(context);
data->task_runner()->RunMessageLoop(true);
}
};
int InspectorTestMain(int argc, char* argv[]) {
v8::V8::InitializeICUDefaultLocation(argv[0]);
std::unique_ptr<Platform> platform(platform::NewDefaultPlatform());
v8::V8::InitializePlatform(platform.get());
v8_flags.abort_on_contradictory_flags = true;
v8::V8::SetFlagsFromCommandLine(&argc, argv, true);
v8::V8::InitializeExternalStartupData(argv[0]);
v8::V8::Initialize();
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
i::DisableEmbeddedBlobRefcounting();
base::Semaphore ready_semaphore(0);
StartupData startup_data = {nullptr, 0};
for (int i = 1; i < argc; ++i) {
if (strcmp(argv[i], "--embed") == 0) {
argv[i++] = nullptr;
printf("Embedding script '%s'\n", argv[i]);
startup_data = i::CreateSnapshotDataBlobInternal(
SnapshotCreator::FunctionCodeHandling::kClear, argv[i], nullptr);
argv[i] = nullptr;
}
}
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
{
InspectorIsolateData::SetupGlobalTasks frontend_extensions;
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
frontend_extensions.emplace_back(new UtilsExtension());
frontend_extensions.emplace_back(new ConsoleExtension());
TaskRunner frontend_runner(std::move(frontend_extensions),
kFailOnUncaughtExceptions, &ready_semaphore,
startup_data.data ? &startup_data : nullptr,
kNoInspector);
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
ready_semaphore.Wait();
int frontend_context_group_id = 0;
RunSyncTask(&frontend_runner,
[&frontend_context_group_id](InspectorIsolateData* data) {
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
frontend_context_group_id = data->CreateContextGroup();
});
InspectorIsolateData::SetupGlobalTasks backend_extensions;
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
backend_extensions.emplace_back(new SetTimeoutExtension());
backend_extensions.emplace_back(new ConsoleExtension());
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
backend_extensions.emplace_back(new InspectorExtension());
TaskRunner backend_runner(
std::move(backend_extensions), kStandardPropagateUncaughtExceptions,
&ready_semaphore, startup_data.data ? &startup_data : nullptr,
kWithInspector);
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
ready_semaphore.Wait();
UtilsExtension::set_backend_task_runner(&backend_runner);
task_runners = {&frontend_runner, &backend_runner};
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
for (int i = 1; i < argc; ++i) {
// Ignore unknown flags.
if (argv[i] == nullptr || argv[i][0] == '-') continue;
bool exists = false;
std::string chars = ReadFile(argv[i], &exists, true);
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
if (!exists) {
FATAL("Internal error: script file doesn't exists: %s\n", argv[i]);
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
}
frontend_runner.Append(std::make_unique<ExecuteStringTask>(
chars, frontend_context_group_id));
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
}
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
frontend_runner.Join();
backend_runner.Join();
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
UtilsExtension::ClearAllSessions();
delete[] startup_data.data;
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
// TaskRunners go out of scope here, which causes Isolate teardown and all
// running background tasks to be properly joined.
}
Reland "[builtins] Support embedded builtins in nosnapshot builds" This is a reland of bf2f0a0227c1233cd42e6e0a928bf968acaf713e Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57540}
2018-11-15 12:49:20 +00:00
i::FreeCurrentEmbeddedBlob();
return 0;
}
} // namespace
} // namespace internal
} // namespace v8
int main(int argc, char* argv[]) {
return v8::internal::InspectorTestMain(argc, argv);
}