Closed Bug 1415197 Opened 2 years ago Closed 2 years ago

Crash near null [@ nsDocumentViewer::Show]

Categories

(Core :: Layout, defect, P3, critical)

52 Branch
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jkratzer, Unassigned)

References

(Blocks 1 open bug)

Details

(4 keywords)

Attachments

(3 files)

Attached file trigger.html
Found while fuzzing mozilla-central rev 4ea775c267be.

Testcase reliability decreases during reduction so the full unreduced testcase has been included here.

==18831==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f4aecf9cd0f bp 0x7ffe6a6a4610 sp 0x7ffe6a6a43a0 T0)
==18831==The signal is caused by a READ memory access.
==18831==Hint: address points to the zero page.
    #0 0x7f4aecf9cd0e in nsDocumentViewer::Show() /builds/worker/workspace/build/src/layout/base/nsDocumentViewer.cpp:2199:13
    #1 0x7f4aed02f37b in nsPresContext::EnsureVisible() /builds/worker/workspace/build/src/layout/base/nsPresContext.cpp:2246:31
    #2 0x7f4aeceb1f83 in mozilla::PresShell::UnsuppressAndInvalidate() /builds/worker/workspace/build/src/layout/base/PresShell.cpp:3896:54
    #3 0x7f4aeceb5945 in mozilla::PresShell::ProcessReflowCommands(bool) /builds/worker/workspace/build/src/layout/base/PresShell.cpp:9207:5
    #4 0x7f4aeceb4767 in mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) /builds/worker/workspace/build/src/layout/base/PresShell.cpp:4233:11
    #5 0x7f4aecea3232 in mozilla::PresShell::DidDoReflow(bool) /builds/worker/workspace/build/src/layout/base/PresShell.cpp:8818:3
    #6 0x7f4aeceb56e8 in mozilla::PresShell::ProcessReflowCommands(bool) /builds/worker/workspace/build/src/layout/base/PresShell.cpp:9174:7
    #7 0x7f4aeceb4767 in mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) /builds/worker/workspace/build/src/layout/base/PresShell.cpp:4233:11
    #8 0x7f4aece27a32 in FlushPendingNotifications /builds/worker/workspace/build/src/obj-firefox/dist/include/nsIPresShell.h:581:5
    #9 0x7f4aece27a32 in nsRefreshDriver::Tick(long, mozilla::TimeStamp) /builds/worker/workspace/build/src/layout/base/nsRefreshDriver.cpp:1921
    #10 0x7f4aece26f72 in nsRefreshDriver::Tick(long, mozilla::TimeStamp) /builds/worker/workspace/build/src/layout/base/nsRefreshDriver.cpp:1843:12
    #11 0x7f4aece30b39 in nsRefreshDriver::FinishedWaitingForTransaction() /builds/worker/workspace/build/src/layout/base/nsRefreshDriver.cpp:2155:5
    #12 0x7f4ae832df10 in mozilla::layers::ClientLayerManager::DidComposite(unsigned long, mozilla::TimeStamp const&, mozilla::TimeStamp const&) /builds/worker/workspace/build/src/gfx/layers/client/ClientLayerManager.cpp:536:32
    #13 0x7f4ae840ef01 in mozilla::layers::CompositorBridgeChild::RecvDidComposite(unsigned long const&, unsigned long const&, mozilla::TimeStamp const&, mozilla::TimeStamp const&) /builds/worker/workspace/build/src/gfx/layers/ipc/CompositorBridgeChild.cpp:543:8
    #14 0x7f4ae7493742 in mozilla::layers::PCompositorBridgeChild::OnMessageReceived(IPC::Message const&) /builds/worker/workspace/build/src/obj-firefox/ipc/ipdl/PCompositorBridgeChild.cpp:1441:20
    #15 0x7f4ae6d42ba9 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) /builds/worker/workspace/build/src/ipc/glue/MessageChannel.cpp:2119:25
    #16 0x7f4ae6d3fbbf in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) /builds/worker/workspace/build/src/ipc/glue/MessageChannel.cpp:2049:17
    #17 0x7f4ae6d412f4 in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) /builds/worker/workspace/build/src/ipc/glue/MessageChannel.cpp:1895:5
    #18 0x7f4ae6d41948 in mozilla::ipc::MessageChannel::MessageTask::Run() /builds/worker/workspace/build/src/ipc/glue/MessageChannel.cpp:1928:15
    #19 0x7f4ae5f5e3a6 in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/workspace/build/src/xpcom/threads/nsThread.cpp:1037:14
    #20 0x7f4ae5f78868 in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/workspace/build/src/xpcom/threads/nsThreadUtils.cpp:513:10
    #21 0x7f4ae6d4a811 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /builds/worker/workspace/build/src/ipc/glue/MessagePump.cpp:97:21
    #22 0x7f4ae6caae6b in RunInternal /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:326:10
    #23 0x7f4ae6caae6b in RunHandler /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:319
    #24 0x7f4ae6caae6b in MessageLoop::Run() /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:299
    #25 0x7f4aec72d92f in nsBaseAppShell::Run() /builds/worker/workspace/build/src/widget/nsBaseAppShell.cpp:158:27
    #26 0x7f4af08469d1 in nsAppStartup::Run() /builds/worker/workspace/build/src/toolkit/components/startup/nsAppStartup.cpp:288:30
    #27 0x7f4af0a3e6ab in XREMain::XRE_mainRun() /builds/worker/workspace/build/src/toolkit/xre/nsAppRunner.cpp:4675:22
    #28 0x7f4af0a40275 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) /builds/worker/workspace/build/src/toolkit/xre/nsAppRunner.cpp:4837:8
    #29 0x7f4af0a41626 in XRE_main(int, char**, mozilla::BootstrapConfig const&) /builds/worker/workspace/build/src/toolkit/xre/nsAppRunner.cpp:4932:21
    #30 0x4ec4ec in do_main /builds/worker/workspace/build/src/browser/app/nsBrowserApp.cpp:231:22
    #31 0x4ec4ec in main /builds/worker/workspace/build/src/browser/app/nsBrowserApp.cpp:304
    #32 0x7f4b03ef082f in __libc_start_main /build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291
Attached file fuzzer.js
Group: core-security
Marking this as SS since the testcase may reveal some logic regarding the fuzzer operations.
Group: core-security → layout-core-security
I'm assuming the DOMFuzzHelper extension is required.  Enabling popup windows
in Preferences seems to be necessary too.  Anything else?
Flags: needinfo?(jkratzer)
(In reply to Mats Palmgren (:mats) from comment #3)
> I'm assuming the DOMFuzzHelper extension is required.  Enabling popup windows
> in Preferences seems to be necessary too.  Anything else?

We've recently enabled web components so you will likely need the following prefs as well:

user_pref("dom.webcomponents.enabled", true);
user_pref("dom.webcomponents.customelements.enabled", true);
Flags: needinfo?(jkratzer)
> We've recently enabled web components so you will likely need the following prefs as well

I'm using a local up-to-date m-c build on Linux and those prefs
are 'false' in a fresh profile.  Presumably those prefs should be
'true' if it's enabled by default?

Anyway, after adding them manually, I still can't reproduce it.
After 30s or so, the content area is filled with gibberish and
I see an "allow persistent storage" doorhanger, but no complaints
from ASAN...
(In reply to Mats Palmgren (:mats) from comment #5)
> > We've recently enabled web components so you will likely need the following prefs as well
> 
> I'm using a local up-to-date m-c build on Linux and those prefs
> are 'false' in a fresh profile.  Presumably those prefs should be
> 'true' if it's enabled by default?
> 
> Anyway, after adding them manually, I still can't reproduce it.
> After 30s or so, the content area is filled with gibberish and
> I see an "allow persistent storage" doorhanger, but no complaints
> from ASAN...

Mats, can you ping me on IRC and I'll provide you with the full pref file we're using for reproduction?
Thanks, but that seems the wrong way to operate.
All the info needed to reproduce a bug should be in the bug report IMO.
It's important that anyone with access can reproduce it, now and more
importantly in the future.  Details that are not on record in Bugzilla
tends to get lost.

I suggest you attach the pref file that was used to trigger this crash,
or provide a link to the precise revision of it in the VCS you use.
Flags: needinfo?(jkratzer)
Attached file prefs-default.js
Flags: needinfo?(jkratzer)
Priority: -- → P3
Using the prefs in comment 8, with the "network.proxy.*" prefs removed, and adding
the prefs in comment 4, I still can't reproduce this crash in a Linux ASAN build.

Jason, can you still reproduce this?
Flags: needinfo?(jkratzer)
(In reply to Mats Palmgren (:mats) from comment #9)
> Using the prefs in comment 8, with the "network.proxy.*" prefs removed, and
> adding
> the prefs in comment 4, I still can't reproduce this crash in a Linux ASAN
> build.
> 
> Jason, can you still reproduce this?

It looks like this was fixed the same day I reported it.  The fix bisects down to:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fb76bb12880ce776bfd8584368be3708b511dfeb&tochange=40df5dd35fdb7ce3652fe4448ac8961c075c928e
Flags: needinfo?(jkratzer)
Thanks for checking.  Nothing stands out to me in that range though.
Bug 1244280 maybe?

There are a handful of reported crashes for this signature,
e.g. bp-cf03903f-a034-44e7-9a3d-343ec0180702
but none of them comes from ProcessReflowCommands AFAICT,
so it doesn't seem warranted to keep tracking this.

Anyway, please reopen this bug or file a new one if you see
this crash again.
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: in-testsuite?
Resolution: --- → WORKSFORME
Group: layout-core-security
You need to log in before you can comment on or make changes to this bug.