logResult[n].extra fails to serialize in worker tests

[ErichDonGubler]

Test: webgpu/cts/webgpu/web_platform/canvas/readbackFromWebGPUCanvas/dedicated.https.html?worker=dedicated&q=webgpu:web_platform,canvas,readbackFromWebGPUCanvas:offscreenCanvas,snapshot:*

This happens because the postMessage call inside of the reportTestResults function in test_worker-worker.js in WebGPU CTS loads data from result, converting result.logs into a form more amenable form for a message via toRawData. However, for this test, the extra field of one or more logs entries is populated and preserved, containing function objects as members.

Standalone CTS doesn't reproduce this by default; one needs to set the debug query parameter first:
https://gpuweb.github.io/cts/standalone/?worker=dedicated&debug=1&q=webgpu:web_platform,canvas,readbackFromWebGPUCanvas:transferToImageBitmap_unconfigured_nonzero_size:*

I presume that the Chrome hasn't run into this because…it passes most of CTS. 😅

[ErichDonGubler]

@kainino0x: If I were to file a PR for this, I think the simplest (naive) approach I might take is to serialize extra to JSON and back before sending it via postMessage. Do you think that might work?

[kainino0x]

Chrome probably doesn't hit this because we don't set debug=1. debug is really intended as an interactive debugging tool (though tbh it's not that likely anyone even uses extra when debugging). So we could try to preserve extra data to improve interactive debugging a bit, but since we can't preserve the original objects, we probably may as well just discard it when serializing.

[ErichDonGubler]

I'm not sure why, but WPT tests for Firefox are running into this as if debug=1, but AFAIK debug=1 is not specified. I made repro steps that got the same behavior for standalone, but I might be reporting an XY problem here. 😅

[ErichDonGubler]

Aha, I think I've diagnosed the above. src/common/runtime/helper/options.ts:64](

cts/src/common/runtime/helper/options.ts

Line 64 in 467b5f7

debug: true,

) sets debugging to true by default, and that's effectively the configuration used for worker contexts in WPT, because src/common/runtime/wpt.ts:35-37 does not provide a non-default configuration.

I think the solution remains the same, but that's an interesting way for the bug's preconditions to be fulfilled in the context I originally observed this bug.

[ErichDonGubler]

Firefox upstream tracking: bug 1943776

[kainino0x]

Ah, hm. I'm not sure why that's true by default, but that could also explain issues we had with over-logging (in chromium) that someone mentioned to me a while ago.

[ErichDonGubler]

This was resolved by #4287.