1614357 - AddressSanitizer: SEGV /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/Assertions.h:332:3 in MOZ_Crash

Reporter

Description

•

4 years ago

Attached file testcase.html — Details

Testcase found while fuzzing mozilla-central rev d3aa4a9e4dfd. Testcase must be served over HTTP in order to reproduce.

==31888==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000001 (pc 0x7fa30a6544b0 bp 0x7ffeeded37b0 sp 0x7ffeeded37a0 T0)
==31888==The signal is caused by a WRITE memory access.
==31888==Hint: address points to the zero page.
    #0 0x7fa30a6544af in MOZ_Crash /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/Assertions.h:332:3
    #1 0x7fa30a6544af in nsAutoOwningThread::AssertCurrentThreadOwnsMe(char const*) const /builds/worker/workspace/build/src/xpcom/base/nsISupportsImpl.cpp:40:5
    #2 0x7fa3123ab9b8 in AssertOwnership<36> /builds/worker/workspace/build/src/obj-firefox/dist/include/nsISupportsImpl.h:59:5
    #3 0x7fa3123ab9b8 in mozilla::dom::RemoteWorkerManager::Release() /builds/worker/workspace/build/src/dom/workers/remoteworkers/RemoteWorkerManager.h:26:3
    #4 0x7fa3123c1d33 in Release /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/RefPtr.h:50:40
    #5 0x7fa3123c1d33 in Release /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/RefPtr.h:379:36
    #6 0x7fa3123c1d33 in ~RefPtr /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/RefPtr.h:81:7
    #7 0x7fa3123c1d33 in ~ /builds/worker/workspace/build/src/dom/workers/remoteworkers/RemoteWorkerManager.cpp:382:17
    #8 0x7fa3123c1d33 in mozilla::Maybe<mozilla::dom::RemoteWorkerManager::LaunchNewContentProcess(mozilla::dom::RemoteWorkerData const&)::$_19::operator()()::'lambda'(mozilla::ipc::LaunchError const&)>::reset() /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/Maybe.h:444:17
    #9 0x7fa3122595d2 in mozilla::MozPromise<RefPtr<mozilla::dom::ContentParent>, mozilla::ipc::LaunchError, false>::ThenValueBase::ResolveOrRejectRunnable::Run() /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/MozPromise.h:403:21
    #10 0x7fa30a7f8358 in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/workspace/build/src/xpcom/threads/nsThread.cpp:1220:14
    #11 0x7fa30a80316c in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/workspace/build/src/xpcom/threads/nsThreadUtils.cpp:486:10
    #12 0x7fa30ba54f6f in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /builds/worker/workspace/build/src/ipc/glue/MessagePump.cpp:87:21
    #13 0x7fa30b94e6d7 in RunInternal /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:315:10
    #14 0x7fa30b94e6d7 in RunHandler /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:308:3
    #15 0x7fa30b94e6d7 in MessageLoop::Run() /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:290:3
    #16 0x7fa312a23a08 in nsBaseAppShell::Run() /builds/worker/workspace/build/src/widget/nsBaseAppShell.cpp:137:27
    #17 0x7fa31631874b in nsAppStartup::Run() /builds/worker/workspace/build/src/toolkit/components/startup/nsAppStartup.cpp:272:30
    #18 0x7fa31652c501 in XREMain::XRE_mainRun() /builds/worker/workspace/build/src/toolkit/xre/nsAppRunner.cpp:4566:22
    #19 0x7fa31652e426 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) /builds/worker/workspace/build/src/toolkit/xre/nsAppRunner.cpp:4701:8
    #20 0x7fa31652f103 in XRE_main(int, char**, mozilla::BootstrapConfig const&) /builds/worker/workspace/build/src/toolkit/xre/nsAppRunner.cpp:4752:21
    #21 0x55e1d397a8ff in do_main /builds/worker/workspace/build/src/browser/app/nsBrowserApp.cpp:217:22
    #22 0x55e1d397a8ff in main /builds/worker/workspace/build/src/browser/app/nsBrowserApp.cpp:331:16
    #23 0x7fa32d2d2b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #24 0x55e1d38cfecc in _start (/home/forb1dden/builds/mc-asan/firefox+0x9becc)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/Assertions.h:332:3 in MOZ_Crash

Flags: in-testsuite?

Jason Kratzer [:jkratzer]

Reporter

Comment 1

•

4 years ago

Attached file worker.js — Details

Jason Kratzer [:jkratzer]

Reporter

Comment 2

•

4 years ago

Attached file prefs.js — Details

Jens Stutte [:jstutte]

Updated

•

4 years ago

Priority: -- → P2

Comment hidden (Intermittent Failures Robot)

BugBot [:suhaib / :marco/ :calixte]

Comment 4

•

4 years ago

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

Ethan Tseng [:ethan]

Comment 5

•

4 years ago

•

Edited

Fix optional because it's a crash from fuzzing tools.

status-firefox75: affected → fix-optional

Comment hidden (Intermittent Failures Robot)

Julien Cristau [:jcristau]

Updated

•

4 years ago

status-firefox75: fix-optional → wontfix

Comment hidden (Intermittent Failures Robot)

Jens Stutte [:jstutte]

Comment 10

•

4 years ago

(In reply to Intermittent Failures Robot from comment #9)

1 failures in 5015 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

try: 1

Platform breakdown:

linux1804-64-asan: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1614357&startday=2020-03-30&endday=2020-04-05&tree=all

I read here that mozilla::dom::MediaRecorder::Session::DoSessionEndTask(nsresult) causes an array index out of bounds on a nsTArray.

Jens Stutte [:jstutte]

Comment 11

•

4 years ago

Hi Gabriele, how come the intermittent robot associate those failures here? The run test is a far-out /mediacapture-record/MediaRecorder-events-and-exceptions.html and the crash looks very different, too.

Flags: needinfo?(gsvelto)

Gabriele Svelto [:gsvelto]

Comment 12

•

4 years ago

It seems that it's only correlating based on the first line of the crash which is the same. I don't know how that tool works but maybe :gbrown can help

Flags: needinfo?(gsvelto) → needinfo?(gbrown)

Geoff Brown [:gbrown]

Comment 13

•

4 years ago

The intermittent robot does not classify the failures, it just reports a summary of how people have classified the failures. In the case of comment 10, that was a try push and the failure was reported against this bug by malexandru (see the Annotations tab in treeherder).

Treeherder tries to identify specific short text sequences that indicate errors and uses those to find bug suggestions -- in this case,

PID 9298 | ==10599==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000001 (pc 0x7fc327de8430 bp 0x7fff58201ae0 sp 0x7fff58201ae0 T0)
PID 9298 | SUMMARY: AddressSanitizer: SEGV /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:332:3 in MOZ_Crash
SSLZeroReturnError: TLS/SSL connection has been closed (EOF) (_ssl.c:1829)
# TBPL FAILURE #

and of course the second line is a close match with this bug's title.

Flags: needinfo?(gbrown)

Comment hidden (Intermittent Failures Robot)

Jens Stutte [:jstutte]

Comment 15

•

4 years ago

Hi Jason, in a current nightly this testcase seems not to reproduce (but I did not do anything with the prefs.js file than copying to the local webserver). Does it still reproduce for you?

Flags: needinfo?(jkratzer)

Jason Kratzer [:jkratzer]

Reporter

Comment 16

•

4 years ago

Jens, I'm unable to reproduce this bug on tip. It appears to have been fixed within the following range:

Start: b0b5ea1916c54c36caed656a69dedb2ac3ced574 (20200213141721)
End: b47e32ff95b8d544ea1e94374e1d5ad8929bba39 (20200213182133)
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b0b5ea1916c54c36caed656a69dedb2ac3ced574&tochange=b47e32ff95b8d544ea1e94374e1d5ad8929bba39

Perhaps bug 1603484?

Flags: needinfo?(jkratzer)

Comment hidden (Intermittent Failures Robot)

Jens Stutte [:jstutte]

Comment 18

•

4 years ago

(In reply to Intermittent Failures Robot from comment #17)

6 failures in 4528 pushes (0.001 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

autoland: 5

mozilla-central: 1

Platform breakdown:

linux1804-64-asan: 6

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1614357&startday=2020-04-13&endday=2020-04-19&tree=all

All of these failures have different origins, AFAIU. I see at least:
DNSRequestChild
MediaRecorder
BackgroundChildImpl
DocGroup

Jason, can we close this and somehow dispatch the other reports to the right components?

Flags: needinfo?(jkratzer)

Jason Kratzer [:jkratzer]

Reporter

Updated

•

4 years ago

Flags: needinfo?(jkratzer)

Comment hidden (Intermittent Failures Robot)

Jens Stutte [:jstutte]

Comment 22

•

3 years ago

In the last three reports I read:

1. report

[task 2020-06-01T10:14:44.266Z] 10:14:44     INFO - PID 6389 |     #0 0x7fbdb9a819cf in MOZ_Crash /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:332:3
[task 2020-06-01T10:14:44.266Z] 10:14:44     INFO - PID 6389 |     #1 0x7fbdb9a819cf in nsAutoOwningThread::AssertCurrentThreadOwnsMe(char const*) const /builds/worker/checkouts/gecko/xpcom/base/nsISupportsImpl.cpp:40:5
[task 2020-06-01T10:14:44.282Z] 10:14:44     INFO - PID 6389 |     #2 0x7fbdbca41b68 in AssertOwnership<25> /builds/worker/workspace/obj-build/dist/include/nsISupportsImpl.h:60:5
[task 2020-06-01T10:14:44.282Z] 10:14:44     INFO - PID 6389 |     #3 0x7fbdbca41b68 in mozilla::dom::DOMArena::Release() /builds/worker/workspace/obj-build/dist/include/mozilla/dom/DOMArena.h:40:3
[task 2020-06-01T10:14:44.389Z] 10:14:44     INFO - PID 6389 |     #4 0x7fbdbcc61f90 in Release /builds/worker/workspace/obj-build/dist/include/mozilla/RefPtr.h:50:40
[task 2020-06-01T10:14:44.390Z] 10:14:44     INFO - PID 6389 |     #5 0x7fbdbcc61f90 in Release /builds/worker/workspace/obj-build/dist/include/mozilla/RefPtr.h:381:36
[task 2020-06-01T10:14:44.390Z] 10:14:44     INFO - PID 6389 |     #6 0x7fbdbcc61f90 in ~RefPtr /builds/worker/workspace/obj-build/dist/include/mozilla/RefPtr.h:81:7
[task 2020-06-01T10:14:44.392Z] 10:14:44     INFO - PID 6389 |     #7 0x7fbdbcc61f90 in mozilla::dom::DocGroup::~DocGroup() /builds/worker/checkouts/gecko/dom/base/DocGroup.cpp:173:1
[task 2020-06-01T10:14:44.392Z] 10:14:44     INFO - PID 6389 |     #8 0x7fbdbcd6b6ab in Release /builds/worker/workspace/obj-build/dist/include/mozilla/dom/DocGroup.h:41:3
[task 2020-06-01T10:14:44.393Z] 10:14:44     INFO - PID 6389 |     #9 0x7fbdbcd6b6ab in Release /builds/worker/workspace/obj-build/dist/include/mozilla/RefPtr.h:50:40
[task 2020-06-01T10:14:44.393Z] 10:14:44     INFO - PID 6389 |     #10 0x7fbdbcd6b6ab in Release /builds/worker/workspace/obj-build/dist/include/mozilla/RefPtr.h:381:36
[task 2020-06-01T10:14:44.393Z] 10:14:44     INFO - PID 6389 |     #11 0x7fbdbcd6b6ab in ~RefPtr /builds/worker/workspace/obj-build/dist/include/mozilla/RefPtr.h:81:7
[task 2020-06-01T10:14:44.394Z] 10:14:44     INFO - PID 6389 |     #12 0x7fbdbcd6b6ab in ~LabellingEventTarget /builds/worker/checkouts/gecko/dom/base/DocGroup.cpp:51:35
[task 2020-06-01T10:14:44.395Z] 10:14:44     INFO - PID 6389 |     #13 0x7fbdbcd6b6ab in (anonymous namespace)::LabellingEventTarget::Release() /builds/worker/checkouts/gecko/dom/base/DocGroup.cpp:91:1
[task 2020-06-01T10:14:44.397Z] 10:14:44     INFO - PID 6389 |     #14 0x7fbdbabf512c in ~nsCOMPtr_base /builds/worker/workspace/obj-build/dist/include/nsCOMPtr.h:329:7
[task 2020-06-01T10:14:44.397Z] 10:14:44     INFO - PID 6389 |     #15 0x7fbdbabf512c in ~NeckoTargetHolder /builds/worker/workspace/obj-build/dist/include/mozilla/net/NeckoTargetHolder.h:25:40
[task 2020-06-01T10:14:44.398Z] 10:14:44     INFO - PID 6389 |     #16 0x7fbdbabf512c in mozilla::DataChannelConnection::~DataChannelConnection() /builds/worker/checkouts/gecko/netwerk/sctp/datachannel/DataChannel.cpp:314:1
[task 2020-06-01T10:14:44.398Z] 10:14:44     INFO - PID 6389 |     #17 0x7fbdbabf5abd in mozilla::DataChannelConnection::~DataChannelConnection() /builds/worker/checkouts/gecko/netwerk/sctp/datachannel/DataChannel.cpp:291:49
[task 2020-06-01T10:14:44.398Z] 10:14:44     INFO - PID 6389 |     #18 0x7fbdbac1337d in mozilla::DataChannelConnectionShutdown::~DataChannelConnectionShutdown() /builds/worker/checkouts/gecko/netwerk/sctp/datachannel/DataChannel.cpp:96:44
[task 2020-06-01T10:14:44.400Z] 10:14:44     INFO - PID 6389 |     #19 0x7fbdbabf454c in mozilla::DataChannelConnectionShutdown::Release() /builds/worker/checkouts/gecko/netwerk/sctp/datachannel/DataChannel.cpp:190:1
[task 2020-06-01T10:14:44.416Z] 10:14:44     INFO - PID 6389 |     #20 0x7fbdb9c50cbf in nsTimerImpl::Callback::clear() /builds/worker/checkouts/gecko/xpcom/threads/nsTimerImpl.h:108:9
[task 2020-06-01T10:14:44.416Z] 10:14:44     INFO - PID 6389 |     #21 0x7fbdb9c4ef3d in nsTimerImpl::Callback::~Callback() /builds/worker/checkouts/gecko/xpcom/threads/nsTimerImpl.h:104:19
[task 2020-06-01T10:14:44.416Z] 10:14:44     INFO - PID 6389 |     #22 0x7fbdb9c246f0 in nsTimerImpl::Fire(int) /builds/worker/checkouts/gecko/xpcom/threads/nsTimerImpl.cpp:596:1
[task 2020-06-01T10:14:44.417Z] 10:14:44     INFO - PID 6389 |     #23 0x7fbdb9c23bc7 in nsTimerEvent::Run() /builds/worker/checkouts/gecko/xpcom/threads/TimerThread.cpp:251:11
[task 2020-06-01T10:14:44.417Z] 10:14:44     INFO - PID 6389 |     #24 0x7fbdb9c368e2 in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:1211:14
[task 2020-06-01T10:14:44.417Z] 10:14:44     INFO - PID 6389 |     #25 0x7fbdb9c40a9c in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.cpp:501:10

So we have a local Callback variable that will start a cascade of deconstructors which ends up destroying a DocGroup on the wrong thread coming through a strong reference in LabellingEventTarget. Maybe we should use a weak reference there and check, if the DocGroup still exists after the timer returns rather than keeping it alife here?

2. report
3. report
Seem to be the same.

LabellingEventTarget has been introduced by bug 1620594. Andreas, can you take a look (and in case re-assign the component of this bug) ?

Flags: needinfo?(afarre)

Andreas Farre [:farre]

Updated

•

3 years ago

Assignee: nobody → afarre

Flags: needinfo?(afarre)

Jens Stutte [:jstutte]

Updated

•

3 years ago

Severity: critical → S3

Andreas Farre [:farre]

Comment 23

•

3 years ago

•

Edited

So this hasn't got anything to do with bug 1620594. If you look at the stacks in comment 22, the assert happens due to DOMArena being destroyed off of main thread, which is reasonable since DOMArena isn't thread safe. DocGroup on the other hand is thread safe, so we expect to get into this situation, and thus need to handle it. I filed a new bug for this issue, since it has nothing to do with RemoteWorkerManager, see bug 1644452.

Assignee: afarre → nobody

Andrew Sutherland [:asuth] (he/him)

Updated

•

3 years ago

Depends on: 1644452

Comment hidden (Intermittent Failures Robot)

Tyson Smith [:tsmith]

Comment 29

•

3 years ago

The attached test case no longer reproduces the issue and the fuzzers last saw this with m-c 20200213-b0b5ea1916c5 (Feb 2020).

testcase.html 4 years ago Jason Kratzer [:jkratzer] 221 bytes, text/html		Details
worker.js 4 years ago Jason Kratzer [:jkratzer] 19 bytes, application/x-javascript		Details
prefs.js 4 years ago Jason Kratzer [:jkratzer] 14.55 KB, application/x-javascript		Details