Graphics corruption and seemingly impossible behavior in WebAssembly/WebGL 2 app

• Component: WebKitGTK
• Status: NEW ---

[Autumn]

Created attachment 469075 [details]
source and built artifacts of the buggy WebAssembly app

Overview:

I get graphics corruption and strange, seemingly impossible errors 4 to 5 percent of the time when I open a Rust WebAssembly app in Epiphany.

I'm reporting these two things as a single bug because so far they've only ever happened in tandem and it seems likely to me that they have a single cause. I've reloaded the buggy page about 200 times each in Firefox and Chromium with no issues.

Steps to reproduce:

Extract trails-editor.tar.gz and enter it. Host a local HTTP server (I use httplz with `--no-encode -H 'Cache-Control: no-store'`) and access it in Epiphany. Open trails.html. Reload until you get corrupted graphics and an error in the console.

Results:

The app usually works fine. (The app won't appear to do anything because of bug 206216, but other than that, there don't seem to be any problems.) But after reloading enough times, I consistently end up encountering an error. I tried reloading 100 times in Epiphany and Cog and got errors 4 out of 100 times in Epiphany and 5 out of 100 times in Cog. (Or I at least got the graphics corruption in Cog. I didn't see any console output. I don't know if Cog lets you access the console.)

Each time an error occurs, two things happen. The page is filled with what appear to be the contents of uninitialized GPU memory, scaled up from a low resolution with linear filtering. I've seen window decorations from other running applications appear several times. (I've tried extracting these pixels with toDataURL and just got a blank image.) And the application fails to start, printing a stack trace to the console.

These stack traces can report a wide variety of different errors in completely different parts of the application code. They're often things that seem impossible when looking at the Rust sources. For instance, I sometimes see an error saying `bytemuck::cast_slice` failed because it was passed an under-aligned slice (TargetAlignmentGreaterAndInputNotAligned). But I only ever call that function with a target alignment of 1, and going into the decompiled WebAssembly, I can see that the monomorphized `bytemuck::cast_slice` that appears in the stack trace is indeed specialized to a target alignment of 1. After reading the decompilation, it seems possible that error might appear if that function is passed a null pointer, but that would imply that the Rust standard library somehow produced a Vec with a non-zero length that pointed to null. I also once got an error saying a shader had failed to compile because of a syntax error. I looked at the contents of the module memory, and indeed, there was shader code with a missing semicolon in there. Specifically, the line starting with `#define DAB_VERTICES_DEFINITION` was missing a semicolon at the end, which again seems to be impossible when looking at the code in render.rs. This is 20231215_101108.mem in the "dumps.tar.gz" attachment. Other memory dumps with corresponding stack traces are in that archive as well. (Sorry, I forgot to save the stack trace as a text file in this particular one, but the memory dump is there.)

OS/build info:

Arch Linux x86_64, last updated 2023-12-15T00:32:05-0800
uname -a:
Linux moonsetter 6.6.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 14 Dec 2023 03:45:42 +0000 x86_64 GNU/Linux

Epiphany 45.1-1 (arch) with webkitgtk-6.0 2.42.3-1 (arch)
Cog 0.18.0-1 (AUR) with wpewebkit 2.42.3-1 (arch) and wpebackend-fdo 1.14.2-1 (arch)
Firefox 120.0.1-1 (arch)
Chromium 120.0.6099.109-1 (arch)

Build info for the buggy WebAssembly app:

rustc -vV (toolchain installed via rustup):
rustc 1.74.1 (a28077b28 2023-12-04)
binary: rustc
commit-hash: a28077b28a02b92985b3a3faecf92813155f1ea1
commit-date: 2023-12-04
host: x86_64-unknown-linux-gnu
release: 1.74.1
LLVM version: 17.0.4

build command (using wasm-pack 0.12.1)
wasm-pack build --dev --target web

[Autumn]

Created attachment 469076 [details]
memory dumps and corresponding stack traces

[Autumn]

Now that I've had the opportunity to try this on Safari: I can't reproduce any of this in Safari 17.3 (18617.2.4.11.9, 18617) on OSX 13.6.4.