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. :-)