Closed Bug 1687191 Opened 5 years ago Closed 3 years ago

shutdown crash in [@ mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal]

Categories

(Core :: XPCOM, defect)

defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox86 --- affected

People

(Reporter: tsmith, Unassigned)

References

Details

This was seen while trying to reproduce another issue. There is a rr trace and I will add a link to a Pernosco session shortly.

==12371==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x58d932264045 bp 0x7ffc40f22c20 sp 0x7ffc40f22a70 T12371)
==12371==The signal is caused by a READ memory access.
==12371==Hint: address points to the zero page.
    #0 0x58d932264045 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) src/xpcom/threads/TaskController.cpp:648:15
    #1 0x58d932263209 in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) src/xpcom/threads/TaskController.cpp:598:15
    #2 0x58d932263491 in mozilla::TaskController::ProcessPendingMTTask(bool) src/xpcom/threads/TaskController.cpp:382:36
    #3 0x58d93226595a in mozilla::TaskController::InitializeInternal()::$_3::operator()() const src/xpcom/threads/TaskController.cpp:123:37
    #4 0x58d9322658cd in mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_3>::Run() src/objdir-ff-debug/dist/include/nsThreadUtils.h:534:5
    #5 0x58d9322958e7 in nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1200:14
    #6 0x58d9322923df in NS_ProcessPendingEvents(nsIThread*, unsigned int) src/xpcom/threads/nsThreadUtils.cpp:496:19
    #7 0x58d93231ac82 in mozilla::ShutdownXPCOM(nsIServiceManager*) src/xpcom/build/XPCOMInit.cpp:666:5
    #8 0x58d93231a8d4 in NS_ShutdownXPCOM src/xpcom/build/XPCOMInit.cpp:564:10
    #9 0x58d93ccd584b in XRE_TermEmbedding() src/toolkit/xre/nsEmbedFunctions.cpp:212:3
    #10 0x58d933458b02 in mozilla::ipc::ScopedXREEmbed::Stop() src/ipc/glue/ScopedXREEmbed.cpp:90:5
    #11 0x58d939264a2e in mozilla::dom::ContentProcess::CleanUp() src/dom/ipc/ContentProcess.cpp:202:44
    #12 0x58d93ccd653e in XRE_InitChildProcess(int, char**, XREChildData const*) src/toolkit/xre/nsEmbedFunctions.cpp:737:16
    #13 0x58d93cce6536 in mozilla::BootstrapImpl::XRE_InitChildProcess(int, char**, XREChildData const*) src/toolkit/xre/Bootstrap.cpp:67:12
    #14 0x55d0dc470eb7 in content_process_main(mozilla::Bootstrap*, int, char**) src/browser/app/../../ipc/contentproc/plugin-container.cpp:57:28
    #15 0x55d0dc4710c5 in main src/browser/app/nsBrowserApp.cpp:306:18
    #16 0x661f3c38ab96 in __libc_start_main /build/glibc-2ORdQG/glibc-2.27/csu/../csu/libc-start.c:310
    #17 0x55d0dc44f089 in _start (src/objdir-ff-debug/dist/bin/firefox+0xca089)
See Also: → 1690592
See Also: 1690592
See Also: → 1691517

I see this happen in the wild, apparently, but only for versions up to 102. Tyson, did you ever see this again on more recent builds?

Flags: needinfo?(twsmith)

No sorry I haven't. It was last reported by fuzzer in Feb 2021 (m-c 20210217-6d7590bfd8d3).

Flags: needinfo?(twsmith)

Thanks! Actually the signatures in the wild point to other places, apparently (that function is long), but not seeing this since Feb 2021 is probably enough to just close this.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.