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