Re: Trying to crack the Firefox crashing issue

> On May 11, 2025, at 07:01, Damien Stewart <[email protected]> wrote:
> 
> 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.

I don’t know that RLBox has ever worked on BE targets.

It is a separate project that can be built and tested outside Firefox. If someone got enthusiastic about looking into it I guess you could start there.

K


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