Re: Trying to crack the Firefox crashing issue
On 10/5/25 12:46 am, Ken Cunningham wrote:
chatgpt has opinions.
I put in my original run and backtrace from Nov 2023, and chatgpt had
the following to say:
The other night I was wonder if AI could assist in tracking down the
issue. Given WASM used to work AFAIK, perhaps some AI assisted bisecting
is in order.
Thread 1 "firefox" received signal SIGSEGV, Segmentation fault.
i32_load8_u (addr=2014643200, mem=<optimized out>) at rlbox.wasm.c:146
Though I didn't see i32_load8_u come up in my trace it does show up if I
single step to the crash.
==========================
The backtrace you've posted shows a **segmentation fault** (`SIGSEGV`)
happening in Firefox when running under GDB on a PowerPC64 Linux
system. The crash occurs in code generated by RLBox, specifically in
`i32_load8_u` within `rlbox.wasm.c`, which appears to be part of a
**WebAssembly sandboxed execution environment**. Here's a breakdown:
A breakdown in markdown. :-D
### Key Observations:
* **Faulting function**: `i32_load8_u (addr=2014643200)` — the address
accessed is very large and likely invalid.
* **Sandbox**: RLBox is being used — this is a sandboxing framework to
isolate parts of code, such as XML parsers or other libraries, via
WebAssembly.
* **Fault path**:
Interesting it mentions XML here.
* `w2c_rlbox_getEncodingIndex` → `w2c_rlbox_MOZ_XmlInitEncodingNS_0`
→ `w2c_rlbox_prologInitProcessor` → eventually called via
`nsExpatDriver::ParseChunk`
* This indicates the crash is happening during XML parsing inside
the sandbox, possibly parsing a stylesheet (`global.css` is mentioned
in the XML).
### Possible Causes:
1. **Invalid pointer dereference** inside the sandbox — RLBox is
trying to access memory at an address it shouldn't.
2. **Improper input data or parser state**, especially related to XML
or encoding parsing.
3. **Compiler bug or undefined behavior** in sandboxed code generation.
4. **Architecture-specific issue** (PowerPC64) — most testing happens
on x86/x86\_64, so bugs may surface on less common platforms.
### What You Can Do:
1. **Check if the address `2014643200` makes sense** in your sandbox —
it's very high and likely an invalid offset into the RLBox memory.
2. **Enable RLBox debugging**:
It's exactly an invalid offset. Confirmed by the crash itself. The EA is
out of range.
* Build Firefox with `--enable-debug` and set RLBox-related
environment variables like:
```bash
MOZ_RLBOX_SANDBOXED=1
MOZ_RLBOX_VERBOSE=1
```
* This might produce logs that indicate why the memory is invalid.
3. **Verify XML input**: Try to locate and examine the file or network
resource being parsed — malformed or unexpected input could cause faults.
4. **Update Firefox**: Ensure you’re running the latest version of
Firefox and all dependencies.
5. **File a bug**:
* This may be a platform-specific bug. Mozilla tracks RLBox bugs
[on Bugzilla](https://bugzilla.mozilla.org/). Include architecture
(PowerPC64), the RLBox call path, and the faulty address.
Good luck! GPT :-D
Would you like help inspecting the specific value at `addr=2014643200`
or guidance on how to reproduce the crash more minimally?
Yes. Swap it around. :-)
--
My regards,
Damien Stewart.
Reply to: