Closed Bug 1953171 Opened 5 days ago Closed 3 days ago

Assertion failure: !HasTimeouts(), at /dom/base/TimeoutManager.cpp:945

Categories

(Core :: DOM: Workers, defect, P2)

defect

Tracking

()

VERIFIED FIXED
138 Branch
Tracking Status
firefox-esr128 --- unaffected
firefox136 --- unaffected
firefox137 --- unaffected
firefox138 --- verified

People

(Reporter: jkratzer, Assigned: aiunusov)

References

(Blocks 1 open bug, Regression)

Details

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

Attachments

(2 files)

Testcase found while fuzzing mozilla-central rev df246d46dadf (built with: --enable-debug --enable-fuzzing).

Testcase can be reproduced using the following commands:

$ pip install fuzzfetch grizzly-framework --upgrade
$ python -m fuzzfetch --build df246d46dadf --debug --fuzzing  -n firefox
$ python -m grizzly.replay.bugzilla ./firefox/firefox <bugid>
Assertion failure: !HasTimeouts(), at /dom/base/TimeoutManager.cpp:945

    ==2064139==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f67a172de30 bp 0x7f678e0fb220 sp 0x7f678e0fb180 T2064356)
    ==2064139==The signal is caused by a WRITE memory access.
    ==2064139==Hint: address points to the zero page.
        #0 0x7f67a172de30 in MOZ_CrashSequence /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:267:3
        #1 0x7f67a172de30 in mozilla::dom::TimeoutManager::RunTimeout(mozilla::TimeStamp const&, mozilla::TimeStamp const&, bool) /dom/base/TimeoutManager.cpp:945:11
        #2 0x7f67a172c1ed in mozilla::dom::TimeoutExecutor::MaybeExecute() /dom/base/TimeoutExecutor.cpp:179:11
        #3 0x7f67a172e265 in Notify /dom/base/TimeoutExecutor.cpp:246:5
        #4 0x7f67a172e265 in non-virtual thunk to mozilla::dom::TimeoutExecutor::Notify(nsITimer*) /dom/base/TimeoutExecutor.cpp
        #5 0x7f679f7083a4 in operator() /xpcom/threads/nsTimerImpl.cpp:677:44
        #6 0x7f679f7083a4 in matchN<mozilla::Variant<nsTimerImpl::UnknownCallback, nsCOMPtr<nsITimerCallback>, nsCOMPtr<nsIObserver>, nsTimerImpl::FuncCallback, nsTimerImpl::ClosureCallback> &, (lambda at /xpcom/threads/nsTimerImpl.cpp:677:7), (lambda at /xpcom/threads/nsTimerImpl.cpp:678:7), (lambda at /xpcom/threads/nsTimerImpl.cpp:681:7), (lambda at /xpcom/threads/nsTimerImpl.cpp:682:7)> /builds/worker/workspace/obj-build/dist/include/mozilla/Variant.h:309:16
        #7 0x7f679f7083a4 in matchN<mozilla::Variant<nsTimerImpl::UnknownCallback, nsCOMPtr<nsITimerCallback>, nsCOMPtr<nsIObserver>, nsTimerImpl::FuncCallback, nsTimerImpl::ClosureCallback> &, (lambda at /xpcom/threads/nsTimerImpl.cpp:676:7), (lambda at /xpcom/threads/nsTimerImpl.cpp:677:7), (lambda at /xpcom/threads/nsTimerImpl.cpp:678:7), (lambda at /xpcom/threads/nsTimerImpl.cpp:681:7), (lambda at /xpcom/threads/nsTimerImpl.cpp:682:7)> /builds/worker/workspace/obj-build/dist/include/mozilla/Variant.h:318:14
        #8 0x7f679f7083a4 in matchN<mozilla::Variant<nsTimerImpl::UnknownCallback, nsCOMPtr<nsITimerCallback>, nsCOMPtr<nsIObserver>, nsTimerImpl::FuncCallback, nsTimerImpl::ClosureCallback> &, (lambda at /xpcom/threads/nsTimerImpl.cpp:676:7), (lambda at /xpcom/threads/nsTimerImpl.cpp:677:7), (lambda at /xpcom/threads/nsTimerImpl.cpp:678:7), (lambda at /xpcom/threads/nsTimerImpl.cpp:681:7), (lambda at /xpcom/threads/nsTimerImpl.cpp:682:7)> /builds/worker/workspace/obj-build/dist/include/mozilla/Variant.h:902:12
        #9 0x7f679f7083a4 in match<(lambda at /xpcom/threads/nsTimerImpl.cpp:676:7), (lambda at /xpcom/threads/nsTimerImpl.cpp:677:7), (lambda at /xpcom/threads/nsTimerImpl.cpp:678:7), (lambda at /xpcom/threads/nsTimerImpl.cpp:681:7), (lambda at /xpcom/threads/nsTimerImpl.cpp:682:7)> /builds/worker/workspace/obj-build/dist/include/mozilla/Variant.h:857:12
        #10 0x7f679f7083a4 in nsTimerImpl::Fire(int) /xpcom/threads/nsTimerImpl.cpp:675:22
        #11 0x7f679f7076c0 in nsTimerEvent::Run() /xpcom/threads/TimerThread.cpp:515:11
        #12 0x7f67a4a243a4 in mozilla::dom::(anonymous namespace)::ExternalRunnableWrapper::WorkerRun(JSContext*, mozilla::dom::WorkerPrivate*) /dom/workers/WorkerPrivate.cpp:222:37
        #13 0x7f67a4a1514a in mozilla::dom::WorkerThreadRunnable::Run() /dom/workers/WorkerRunnable.cpp:443:12
        #14 0x7f679f7143fa in nsThread::ProcessNextEvent(bool, bool*) /xpcom/threads/nsThread.cpp:1153:16
        #15 0x7f679f71a85f in NS_ProcessNextEvent(nsIThread*, bool) /xpcom/threads/nsThreadUtils.cpp:480:10
        #16 0x7f67a4a020aa in mozilla::dom::WorkerPrivate::DoRunLoop(JSContext*) /dom/workers/WorkerPrivate.cpp:3713:7
        #17 0x7f67a49e7659 in mozilla::dom::workerinternals::(anonymous namespace)::WorkerThreadPrimaryRunnable::Run() /dom/workers/RuntimeService.cpp:2175:42
        #18 0x7f679f7143fa in nsThread::ProcessNextEvent(bool, bool*) /xpcom/threads/nsThread.cpp:1153:16
        #19 0x7f679f71a85f in NS_ProcessNextEvent(nsIThread*, bool) /xpcom/threads/nsThreadUtils.cpp:480:10
        #20 0x7f67a027acc8 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) /ipc/glue/MessagePump.cpp:299:20
        #21 0x7f67a01d4541 in RunHandler /ipc/chromium/src/base/message_loop.cc:362:3
        #22 0x7f67a01d4541 in MessageLoop::Run() /ipc/chromium/src/base/message_loop.cc:344:3
        #23 0x7f679f70fd17 in nsThread::ThreadFunc(void*) /xpcom/threads/nsThread.cpp:366:10
        #24 0x7f67af7bc9df in _pt_root /nsprpub/pr/src/pthreads/ptthread.c:191:3
        #25 0x7f67af861aa3 in start_thread nptl/pthread_create.c:447:8
        #26 0x7f67af8eec3b in clone3 misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
    
    ==2064139==Register values:
    rax = 0x0000000000000000  rbx = 0x00007f66dc032de0  rcx = 0x00000000000003b1  rdx = 0x00007f67af9c9563  
    rdi = 0x00007f67af9ca700  rsi = 0x0000000000000000  rbp = 0x00007f678e0fb220  rsp = 0x00007f678e0fb180  
     r8 = 0x0000000000000000   r9 = 0x0000000000000003  r10 = 0x0000000000000000  r11 = 0x0000000000000293  
    r12 = 0x0000000000000000  r13 = 0x0000000000000000  r14 = 0x0000000000000001  r15 = 0x000063c6a1403a10  
    UndefinedBehaviorSanitizer can not provide additional info.
    SUMMARY: UndefinedBehaviorSanitizer: SEGV /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:267:3 in MOZ_CrashSequence
    ==2064139==ABORTING
Attached file Testcase โ€”

Marking a fuzzblocker, please prioritize appropriately.

Keywords: assertion
OS: Linux → Unspecified
Hardware: x86_64 → Unspecified
Whiteboard: [bugmon:confirm] → [bugmon:confirm][fuzzblocker]

Verified bug as reproducible on mozilla-central 20250311212727-97fe6a90f114.
The bug appears to have been introduced in the following build range:

Start: 64d3da1d46e609750004ae82bb5013b3f258eb1a (20250304171740)
End: ae36d6f29777ff2a99edc4beeb66956cb368f1d9 (20250304180706)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=64d3da1d46e609750004ae82bb5013b3f258eb1a&tochange=ae36d6f29777ff2a99edc4beeb66956cb368f1d9

Keywords: regression
Whiteboard: [bugmon:confirm][fuzzblocker] → [bugmon:bisected,confirmed][fuzzblocker]
Flags: needinfo?(aiunusov)
Severity: -- → S2
Component: DOM: Core & HTML → DOM: Workers
Priority: -- → P2
Regressed by: 1945470
Assignee: nobody → aiunusov
Flags: needinfo?(aiunusov)

So,
// Since ClearAllTimeouts() was called the lists should be empty.
MOZ_DIAGNOSTIC_ASSERT(!HasTimeouts());

ClearAllTimeouts() is called, timeout_was_cleared set to true,
but MOZ_DIAGNOSTIC_ASSERT(!HasTimeouts()); failed

checking how do we clear timeouts and update timeout_was_cleared flag

Set release status flags based on info from the regressing bug 1945470

I think we have a data race here between TimeoutManager::RunTimeout() which is called by TimeoutExecutor and void TimeoutManager::ClearAllTimeouts() which is called from WorkerScope
here, probably we have a RunTimeout() at the moment: https://searchfox.org/mozilla-central/source/dom/base/TimeoutManager.cpp#1087

I will try to reproduce it locally and see, if adding a mutex solves issue and push the patch today soon

  • added a mutex to solve the data race

mutex solved the issue
but I think we must add it to another methods that share the same data with RunTimeout()

okay, sounds like by the mutex I just introduced a dead lock.

figuring out, whats wrong there with that assert

thanks for the test case

Attachment #9471452 - Attachment description: Bug 1953171 - Assertion failure: !HasTimeouts(), at /dom/base/TimeoutManager.cpp:945, r=smaug → WIP: Bug 1953171 - Assertion failure: !HasTimeouts(), at /dom/base/TimeoutManager.cpp:945, r=smaug
Attachment #9471452 - Attachment description: WIP: Bug 1953171 - Assertion failure: !HasTimeouts(), at /dom/base/TimeoutManager.cpp:945, r=smaug → Bug 1953171 - Assertion failure: !HasTimeouts(), at /dom/base/TimeoutManager.cpp:945, r=smaug
Attachment #9471452 - Attachment description: Bug 1953171 - Assertion failure: !HasTimeouts(), at /dom/base/TimeoutManager.cpp:945, r=smaug → WIP: Bug 1953171 - Assertion failure: !HasTimeouts(), at /dom/base/TimeoutManager.cpp:945, r=smaug
Attachment #9471452 - Attachment description: WIP: Bug 1953171 - Assertion failure: !HasTimeouts(), at /dom/base/TimeoutManager.cpp:945, r=smaug → Bug 1953171 - Assertion failure: !HasTimeouts(), at /dom/base/TimeoutManager.cpp:945, r=smaug
Attachment #9471452 - Attachment description: Bug 1953171 - Assertion failure: !HasTimeouts(), at /dom/base/TimeoutManager.cpp:945, r=smaug → WIP: Bug 1953171 - Assertion failure: !HasTimeouts(), at /dom/base/TimeoutManager.cpp:945, r=smaug
Attachment #9471452 - Attachment description: WIP: Bug 1953171 - Assertion failure: !HasTimeouts(), at /dom/base/TimeoutManager.cpp:945, r=smaug → Bug 1953171 - Assertion failure: !HasTimeouts(), at /dom/base/TimeoutManager.cpp:945, r=smaug
Pushed by aiunusov@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b5256ab737d9 Assertion failure: !HasTimeouts(), at /dom/base/TimeoutManager.cpp:945, r=smaug
Status: NEW → RESOLVED
Closed: 3 days ago
Resolution: --- → FIXED
Target Milestone: --- → 138 Branch

Verified bug as fixed on rev mozilla-central 20250314044514-9618bcf19292.
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: