b2d9fd3352
When allocating ExecutionContext, we were skipping allocating constants, because they are filled in shortly after. However, there is still some code executing between allocating the ExecutionContext and assigning constants. This code may allocate GC-aware objects before the assignment. Allocating any GC object may cause a garbage collection to be triggered. And running garbage collection on uninitialized objects might have all kinds of unintended effects. To avoid that, simply initialize constants right away. To be safe, also initialize arguments, but I haven't checked more closely if it is needed for them or not. The specific case where this bug manifested was JetStream3's raytrace-private-class-fields.js, which was triggering a segmentation fault when trying to visit a functions constant during GC marking phase. The offending allocation triggering the garbage collection is the corresponding FunctionEnvironment being created. This crash was exposed as a combination of multiple things coming together. In particular, both of1179e40d3fand61e6dbe4e7combined were exposing the problem, but is seems neither commit is at fault. Most likely the crash happening or not is sensitive to the exact amount of GC pressure being present or size of individual execution contexts. And so any change that affects those might make it appear or go away. To put in an additional wrinkle, this could only be observed using the ASM JS interpreter. The CPP interpreter was using a fast path for function calls that has a different allocation pattern and did not run into the crash. No explicit regression test for this change because: * The problem is very sensitive to implementation details and a reproduction that stays valid with code changes in the interpreter is probably impossible to come by. * The bug was exposed by the JS benchmarks, which already are as good as a regression test as we are going to get here realistically.
Ladybird
Ladybird is a truly independent web browser, using a novel engine based on web standards.
Important
Ladybird is in a pre-alpha state, and only suitable for use by developers
Features
We aim to build a complete, usable browser for the modern web.
Ladybird uses a multi-process architecture with a main UI process, several WebContent renderer processes, an ImageDecoder process, and a RequestServer process.
Image decoding and network connections are done out of process to be more robust against malicious content. Each tab has its own renderer process, which is sandboxed from the rest of the system.
At the moment, many core library support components are inherited from SerenityOS:
- LibWeb: Web rendering engine
- LibJS: JavaScript engine
- LibWasm: WebAssembly implementation
- LibCrypto/LibTLS: Cryptography primitives and Transport Layer Security
- LibHTTP: HTTP/1.1 client
- LibGfx: 2D Graphics Library, Image Decoding and Rendering
- LibUnicode: Unicode and locale support
- LibMedia: Audio and video playback
- LibCore: Event loop, OS abstraction layer
- LibIPC: Inter-process communication
How do I build and run this?
See build instructions for information on how to build Ladybird.
Ladybird runs on Linux, macOS, Windows (with WSL2), and many other *Nixes.
How do I read the documentation?
Code-related documentation can be found in the documentation folder.
Get in touch and participate!
Join our Discord server to participate in development discussion.
Please read Getting started contributing if you plan to contribute to Ladybird for the first time.
Before opening an issue, please see the issue policy and the detailed issue-reporting guidelines.
The full contribution guidelines can be found in CONTRIBUTING.md.
License
Ladybird is licensed under a 2-clause BSD license.