This fixes in a segmentation fault when dropping a `BackingStore`
constructed through `ArrayBuffer::new_backing_store_from_boxed_slice()`
from an empty slice, since zero length boxed slices are invalid
(dangling) pointers, while Rust expects a `Box<c_void>` to always be a
valid pointer.
Fixes: #849
This patch includes a test for this issue.
The V8 patch is intentionally left simple to avoid merge conflicts in
the future. To be landed upstream, the `unwindinfo_use_count_` would
probably have to be made non-atomic and we'd have to add a cctest.
Upstream bug: https://bugs.chromium.org/p/v8/issues/detail?id=12393
Fixes: #714
The pointer returned by `BackingStore::data` might be null if the
backing store has zero length, but the return type `*mut c_void` does
not force the user to consider this case. This change makes the return
type `Option<NonNull<c_void>>`, which is semantically equivalent, but
which forces users of the API to handle the `None` case.
This is a breaking API change.
For zero-size `BackingStore`s, it seems like `BackingStore::data` always
returns a null pointer. The `Deref` impl for `BackingStore` called
`std::slice::from_raw_parts` on that pointer, even though it is UB to
call that function on a null pointer even for empty slices. This change
fixes that by obtaining a valid pointer from `NonNull::dangling()` if
the original is null.
Reported in
https://github.com/denoland/rusty_v8/issues/711#issuecomment-950637136.
Best case, it produces serialized output that cannot be deserialized.
Worst case, it hits this assert in V8:
# Fatal error in v8::FromJust
# Maybe value is Nothing.
Serializing `new String("")` requires that the wire format header is
written, otherwise V8 assumes an incompatible legacy wire format when
deserializing.
The test started a new thread that slept for a bit, then terminated the
isolate, assuming that the delay was long enough for the isolate and the
context to get fully initialized. It wasn't.
Fixes #710.
This commit adds the following methods:
* `FunctionTemplate::inherit()`
* `FunctionTemplate::prototype_template()`
* `FunctionTemplate::read_only_prototype()`
* `FunctionTemplate::remove_prototype()`
This commit adds support for import assertions.
Major changes include:
- removal of "ResolveCallback" (deprecated in V8)
in favor of "ModuleResolveCallback"
- removal of "HostImportModuleDynamicallyCallback" (deprecated in V8)
in favor of "HostImportModuleDynamicallyWithImportAssertionsCallback"
This commit removes the set_flags_from_command_line_with_usage and puts
it in an example code section instead.
The motivation for doing this is that the test output currently contains
the usage string and all the V8 options which creates a lot of output
when the tests is run regardless if --nocapture is used or not.
The blanket `std:#️⃣:Hash` impl for instances of `v8::Data` invokes
`v8::internal::Object::GetHash()` but that crashes for `v8::Module`
objects. Use a custom impl that calls `v8::Module::get_identity_hash()`.
Fixes the following runtime assertion:
# Fatal error in ../../../v8/src/objects/objects-inl.h, line 1043
# Debug check failed: object.IsJSReceiver().
Refs: https://github.com/denoland/deno/pull/8354#discussion_r522157813
After the upgrade some Deno tests started crashing somewhere deep inside
V8, and the cause of these crashes is unclear.
This reverts the following commits:
* 12334ffe Upgrade gn to 6f13aaac; make BUILD.gn compatible with it (#443)
* f53f10d4 Upgrade V8 to 8.7.25 (#443)
Isolate::run_microtasks() already exists but the microtasks queue
is also flushed on script entry and exit. Some embedders want strict
control over when microtasks run, which is set by the policy.
And deprecate Isolate::run_microtasks(). The corresponding V8 API is
tagged with V8_DEPRECATE_SOON.
After upgrading to V8 8.6.337, with a 20 MB heap limit, the
near-heap-limit callback never gets called before V8 runs out of memory.
It turns out that this test exhibits memory allocation behavior which
produces so little actual garbage that 'scavenge' type garbage
collections make memory usage go up rather than down. Because of this,
V8 runs out of memory in the middle of a garbage collection cycle, after
it has already decided that there's no need to run the near-heap-limit
callback.
The issue is fixed by making sure that some actual garbage is produced
alongside with the retained objects that will eventually fill up the
heap.