Closed Bug 1752538 Opened 2 years ago Closed 2 years ago

AddressSanitizer: ILL on unknown address 0x7fea8fcf1c78 [@ mozilla::webgpu::BeginRenderPass]

Categories

(Core :: Graphics: WebGPU, defect, P2)

x86_64
Linux
defect

Tracking

()

VERIFIED FIXED
102 Branch
Tracking Status
firefox102 --- verified

People

(Reporter: jkratzer, Assigned: jimb, NeedInfo)

References

(Blocks 3 open bugs, Regression)

Details

(Keywords: testcase, Whiteboard: [bugmon:bisected,confirmed])

Attachments

(2 files)

Testcase found while fuzzing mozilla-central rev 9530a7bf5efa (built with: --enable-address-sanitizer --enable-fuzzing).

Testcase can be reproduced using the following commands:

$ pip install fuzzfetch grizzly-framework
$ python -m fuzzfetch --build 9530a7bf5efa --asan --fuzzing -n firefox
$ python -m grizzly.replay ./firefox/firefox testcase.html
AddressSanitizer: ILL on unknown address 0x7fea8fcf1c78 [@ mozilla::webgpu::BeginRenderPass]

    =================================================================
    ==2630690==ERROR: AddressSanitizer: ILL on unknown address 0x7fea8fcf1c78 (pc 0x7fea8fcf1c78 bp 0x7ffef4f6fdd0 sp 0x7ffef4f6fac0 T0)
        #0 0x7fea8fcf1c78 in mozilla::webgpu::BeginRenderPass(unsigned long, mozilla::dom::GPURenderPassDescriptor const&) /dom/webgpu/RenderPassEncoder.cpp
        #1 0x7fea8fcf21f7 in mozilla::webgpu::RenderPassEncoder::RenderPassEncoder(mozilla::webgpu::CommandEncoder*, mozilla::dom::GPURenderPassDescriptor const&) /dom/webgpu/RenderPassEncoder.cpp:133:31
        #2 0x7fea8fcd25d0 in mozilla::webgpu::CommandEncoder::BeginRenderPass(mozilla::dom::GPURenderPassDescriptor const&) /dom/webgpu/CommandEncoder.cpp:216:40
        #3 0x7fea8ed7830a in mozilla::dom::GPUCommandEncoder_Binding::beginRenderPass(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) /builds/worker/workspace/obj-build/dom/bindings/WebGPUBinding.cpp:13571:87
        #4 0x7fea8f5c627d in bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) /dom/bindings/BindingUtils.cpp:3306:13
        #5 0x7fea97210994 in CallJSNative /js/src/vm/Interpreter.cpp:425:13
        #6 0x7fea97210994 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /js/src/vm/Interpreter.cpp:512:12
        #7 0x7fea971fcdc5 in CallFromStack /js/src/vm/Interpreter.cpp:576:10
        #8 0x7fea971fcdc5 in Interpret(JSContext*, js::RunState&) /js/src/vm/Interpreter.cpp:3309:16
        #9 0x7fea971e1c21 in js::RunScript(JSContext*, js::RunState&) /js/src/vm/Interpreter.cpp:394:13
        #10 0x7fea97210acf in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /js/src/vm/Interpreter.cpp:544:13
        #11 0x7fea97212c1b in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) /js/src/vm/Interpreter.cpp:589:8
        #12 0x7fea977b2227 in js::CallSelfHostedFunction(JSContext*, JS::Handle<js::PropertyName*>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) /js/src/vm/SelfHosting.cpp:1539:10
        #13 0x7fea97459fa9 in AsyncFunctionResume(JSContext*, JS::Handle<js::AsyncFunctionGeneratorObject*>, ResumeKind, JS::Handle<JS::Value>) /js/src/vm/AsyncFunction.cpp:152:8
        #14 0x7fea9760ff8a in AsyncFunctionPromiseReactionJob /js/src/builtin/Promise.cpp:1949:12
        #15 0x7fea9760ff8a in PromiseReactionJob(JSContext*, unsigned int, JS::Value*) /js/src/builtin/Promise.cpp:2012:12
        #16 0x7fea97210994 in CallJSNative /js/src/vm/Interpreter.cpp:425:13
        #17 0x7fea97210994 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /js/src/vm/Interpreter.cpp:512:12
        #18 0x7fea97212c1b in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) /js/src/vm/Interpreter.cpp:589:8
        #19 0x7fea97490e5d in JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) /js/src/vm/CallAndConstruct.cpp:117:10
        #20 0x7fea8e3b748c in mozilla::dom::PromiseJobCallback::Call(mozilla::dom::BindingCallContext&, JS::Handle<JS::Value>, mozilla::ErrorResult&) /builds/worker/workspace/obj-build/dom/bindings/PromiseBinding.cpp:35:8
        #21 0x7fea89ca57b7 in Call /builds/worker/workspace/obj-build/dist/include/mozilla/dom/PromiseBinding.h:89:12
        #22 0x7fea89ca57b7 in Call /builds/worker/workspace/obj-build/dist/include/mozilla/dom/PromiseBinding.h:102:12
        #23 0x7fea89ca57b7 in mozilla::PromiseJobRunnable::Run(mozilla::AutoSlowOperation&) /xpcom/base/CycleCollectedJSContext.cpp:213:18
        #24 0x7fea89c84627 in mozilla::CycleCollectedJSContext::PerformMicroTaskCheckPoint(bool) /xpcom/base/CycleCollectedJSContext.cpp:674:17
        #25 0x7fea89c8560f in mozilla::CycleCollectedJSContext::AfterProcessTask(unsigned int) /xpcom/base/CycleCollectedJSContext.cpp:463:3
        #26 0x7fea8c2b65e6 in XPCJSContext::AfterProcessTask(unsigned int) /js/xpconnect/src/XPCJSContext.cpp:1478:28
        #27 0x7fea89ec8ee8 in nsThread::ProcessNextEvent(bool, bool*) /xpcom/threads/nsThread.cpp:1232:24
        #28 0x7fea89ed3b7c in NS_ProcessNextEvent(nsIThread*, bool) /xpcom/threads/nsThreadUtils.cpp:467:10
        #29 0x7fea8b3e695f in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /ipc/glue/MessagePump.cpp:85:21
        #30 0x7fea8b26b971 in RunInternal /ipc/chromium/src/base/message_loop.cc:331:10
        #31 0x7fea8b26b971 in RunHandler /ipc/chromium/src/base/message_loop.cc:324:3
        #32 0x7fea8b26b971 in MessageLoop::Run() /ipc/chromium/src/base/message_loop.cc:306:3
        #33 0x7fea921fdc17 in nsBaseAppShell::Run() /widget/nsBaseAppShell.cpp:137:27
        #34 0x7fea96f2e1cf in XRE_RunAppShell() /toolkit/xre/nsEmbedFunctions.cpp:870:20
        #35 0x7fea8b26b971 in RunInternal /ipc/chromium/src/base/message_loop.cc:331:10
        #36 0x7fea8b26b971 in RunHandler /ipc/chromium/src/base/message_loop.cc:324:3
        #37 0x7fea8b26b971 in MessageLoop::Run() /ipc/chromium/src/base/message_loop.cc:306:3
        #38 0x7fea96f2d403 in XRE_InitChildProcess(int, char**, XREChildData const*) /toolkit/xre/nsEmbedFunctions.cpp:707:34
        #39 0x55ce42e1f07d in content_process_main(mozilla::Bootstrap*, int, char**) /browser/app/../../ipc/contentproc/plugin-container.cpp:57:28
        #40 0x55ce42e1f4a8 in main /browser/app/nsBrowserApp.cpp:327:18
        #41 0x7feaae7000b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
        #42 0x55ce42d6e149 in _start (/home/jkratzer/builds/mc-asan/firefox+0x5d149)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: ILL /dom/webgpu/RenderPassEncoder.cpp in mozilla::webgpu::BeginRenderPass(unsigned long, mozilla::dom::GPURenderPassDescriptor const&)
    ==2630690==ABORTING
Attached file Testcase

I get a crash from the testcase, but no crash report is generated.

Bugmon Analysis
Verified bug as reproducible on mozilla-central 20220128155052-48e8fb0b62c5.
The bug appears to have been introduced in the following build range:

Start: 1f856a88914ab02d164fd47e334b03848dae2049 (20210818155306)
End: cfb323870af4cbe082a6e01d3c20786a61165585 (20210818145907)
Pushlog: https://hg.mozilla.org/mozilla-unified/pushloghtml?fromchange=1f856a88914ab02d164fd47e334b03848dae2049&tochange=cfb323870af4cbe082a6e01d3c20786a61165585

Whiteboard: [bugmon:confirm] → [bugmon:bisected,confirmed]

The severity field is not set for this bug.
:kvark, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dmalyshau)
Severity: -- → S3
Priority: -- → P2

The test case attempts to begin a render pass and supplies more color attachments (5) than are permitted (4). This overflows the std::array allocated to hold them. ASan objects to this.

This is an easy problem to fix, if all we care about is not crashing: just truncate the list at the maximum permitted length. What's taking me some time is understanding how to get the error-handling behavior required by the WebGPU specification. WebGPU generally does not require errors to be reported promptly, since doing so could significantly affect the performance of the success case. But I don't yet see how to apply WebGPU's "invalid object" rules to our implementation.

The WebGPU spec says that beginRenderPass should generate a
validation error if the valid usage rules for
GPURenderPassDescriptor are not satisfied. In particular, a
GPURenderPassDescriptor may not contain more than eight color
attachments.

The wgpu-core crate will panic if a
wgpu_core::command::RenderPassDescriptor contains too many color
attachments. This is safe, but panics are not acceptable in Firefox,
so it falls to our WebGPU implementation to perform the error checks
described by the spec.

Since WebGPU error handling records the first error to occur within
each error scope, the API is sensitive to the order in which errors
are generated. To ensure that the error is properly ordered with
respect to other messages sent to the device, we must send the error
to compositor process. The WebGPUParent will then handle it
interleaved appropriately with other Device timeline activity.

Assignee: nobody → jimb
Status: NEW → ASSIGNED

:jimb, since this bug contains a bisection range, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.

Flags: needinfo?(jimb)

(In reply to Bugmon [:jkratzer for issues] from comment #3)

Bugmon Analysis
Verified bug as reproducible on mozilla-central 20220128155052-48e8fb0b62c5.
The bug appears to have been introduced in the following build range:

Start: 1f856a88914ab02d164fd47e334b03848dae2049 (20210818155306)
End: cfb323870af4cbe082a6e01d3c20786a61165585 (20210818145907)
Pushlog: https://hg.mozilla.org/mozilla-unified/pushloghtml?fromchange=1f856a88914ab02d164fd47e334b03848dae2049&tochange=cfb323870af4cbe082a6e01d3c20786a61165585

I do not know why the Start and End changesets are swapped.
Anyway, here is the correct URL.
https://hg.mozilla.org/mozilla-unified/pushloghtml?fromchange=cfb323870af4cbe082a6e01d3c20786a61165585&tochange=1f856a88914ab02d164fd47e334b03848dae2049

Takanori, that was due to a bug in bugmon that has since been fixed. The correct URL should actually be:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1f856a88914ab02d164fd47e334b03848dae2049&tochange=cfb323870af4cbe082a6e01d3c20786a61165585

My guess is bug 1622846?

Pushed by jblandy@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/cc5f20871d68
Properly report GPURenderPassDescriptors with too many color attachments. r=jgilbert
Flags: needinfo?(jimb)
Regressed by: 1622846
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 102 Branch

Bugmon Analysis
Verified bug as fixed on rev mozilla-central 20220517092745-fe9a9b667b38.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

Status: RESOLVED → VERIFIED
Keywords: bugmon
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: