1771033 - Assertion failure: ((bool)(__builtin_expect(!!(!NS_FAILED_impl(result)), 1))), at /dom/cache/FileUtils.cpp:271

Status: NEW

(Core :: Storage: Cache API, defect, P2)

Description

[Jason Kratzer [:jkratzer]]

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

Testcase can be reproduced using the following commands:

$ pip install fuzzfetch grizzly-framework
$ python -m fuzzfetch --build e97c9ea8b858 --debug --fuzzing -n firefox
$ python -m grizzly.replay ./firefox/firefox testcase.zip

Assertion failure: ((bool)(__builtin_expect(!!(!NS_FAILED_impl(result)), 1))), at /dom/cache/FileUtils.cpp:271

    r10 = 0x00007ff836982651	r11 = 0x000000dc9097eba0	r12 = 0x000000dc9097f360
    r13 = 0x000000dc9097f350	r14 = 0x00000000aaaaaaaa	r15 = 0x000000dc9097f2f0
     r8 = 0x000000dc9097fc30	 r9 = 0x00007ff836930000	rax = 0x00007fffd4793fff
    rbp = 0x000000dc9097f2c8	rbx = 0x0000026e25c4f7f8	rcx = 0x00007ff80a833b60
    rdi = 0xaaaaaaaaaaaaaaaa	rdx = 0x0000000000000000	rip = 0x00007fffcdcdc27e
    rsi = 0x000000008052000e	rsp = 0x000000dc9097f1e0
    OS|Windows NT|10.0.19044
    CPU|amd64|family 6 model 158 stepping 10|4
    Crash|EXCEPTION_BREAKPOINT|0x00007fffcdcdc27e|52
    52|0|xul.dll|mozilla::dom::cache::BodyDeleteFiles(mozilla::dom::cache::CacheDirectoryMetadata const&, nsIFile&, nsTArray<nsID> const&)|hg:hg.mozilla.org/mozilla-central:dom/cache/FileUtils.cpp:e97c9ea8b858bbe3a15a3f04a96e4f727a1193a3|284|0xc9e
    52|1|xul.dll|mozilla::dom::cache::`anonymous namespace'::DeleteOrphanedBodyAction::RunOnTarget(mozilla::SafeRefPtr<mozilla::dom::cache::Action::Resolver>, mozilla::Maybe<mozilla::dom::cache::CacheDirectoryMetadata> const&, mozilla::dom::cache::Action::Data*)|hg:hg.mozilla.org/mozilla-central:dom/cache/Manager.cpp:e97c9ea8b858bbe3a15a3f04a96e4f727a1193a3|192|0xb5
    52|2|xul.dll|mozilla::dom::cache::Context::ActionRunnable::Run()|hg:hg.mozilla.org/mozilla-central:dom/cache/Context.cpp:e97c9ea8b858bbe3a15a3f04a96e4f727a1193a3|627|0xbf
    52|3|xul.dll|nsThread::ProcessNextEvent(bool, bool*)|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThread.cpp:e97c9ea8b858bbe3a15a3f04a96e4f727a1193a3|1174|0xa54
    52|4|xul.dll|NS_ProcessNextEvent(nsIThread*, bool)|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThreadUtils.cpp:e97c9ea8b858bbe3a15a3f04a96e4f727a1193a3|465|0x44
    52|5|xul.dll|mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*)|hg:hg.mozilla.org/mozilla-central:ipc/glue/MessagePump.cpp:e97c9ea8b858bbe3a15a3f04a96e4f727a1193a3|300|0xc6
    52|6|xul.dll|MessageLoop::RunHandler()|hg:hg.mozilla.org/mozilla-central:ipc/chromium/src/base/message_loop.cc:e97c9ea8b858bbe3a15a3f04a96e4f727a1193a3|373|0x4f
    52|7|xul.dll|MessageLoop::Run()|hg:hg.mozilla.org/mozilla-central:ipc/chromium/src/base/message_loop.cc:e97c9ea8b858bbe3a15a3f04a96e4f727a1193a3|355|0x6f
    52|8|xul.dll|static nsThread::ThreadFunc(void*)|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThread.cpp:e97c9ea8b858bbe3a15a3f04a96e4f727a1193a3|378|0x141
    52|9|nss3.dll|PR_NativeRunThread(void*)|hg:hg.mozilla.org/mozilla-central:nsprpub/pr/src/threads/combined/pruthr.c:e97c9ea8b858bbe3a15a3f04a96e4f727a1193a3|399|0x111
    52|10|nss3.dll|pr_root(void*)|hg:hg.mozilla.org/mozilla-central:nsprpub/pr/src/md/windows/w95thred.c:e97c9ea8b858bbe3a15a3f04a96e4f727a1193a3|139|0x10
    52|11|ucrtbase.dll||||
    52|12|KERNELBASE.dll||||
    52|13|ucrtbase.dll||||
    52|14|kernel32.dll||||
    52|15|ucrtbase.dll||||
    52|16|mozglue.dll|patched_BaseThreadInitThunk(int, void*, void*)|hg:hg.mozilla.org/mozilla-central:toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp:e97c9ea8b858bbe3a15a3f04a96e4f727a1193a3|572|0x93
    52|17|ntdll.dll||||
    52|18|KERNELBASE.dll||||

Comment 1

[Jason Kratzer [:jkratzer]]

Attachment: Testcase

Comment 2

[Jason Kratzer [:jkratzer]]

This was marked as S-S inadvertently.

Comment 3

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: WIP: Bug 1771033

Comment 4

[Kagami Rosylight [:saschanaz] (they/them)]

This is a shutdown crash, and writing a test for a shutdown crash... is hard, if not impossible.

WPT does not report shutdown crash at all, while Gecko crashtest seemingly runs on file:/// and thus no window.caches support. (Per the spec it should be only available on secure context, btw.)

Comment 5

[Timothy Nikkel (:tnikkel)]

(In reply to Kagami :saschanaz from comment #4)

This is a shutdown crash, and writing a test for a shutdown crash... is hard, if not impossible.

WPT does not report shutdown crash at all, while Gecko crashtest seemingly runs on file:/// and thus no window.caches support. (Per the spec it should be only available on secure context, btw.)

If you add HTTP to the ini file then reftest/crashtest supports loading the page from http instead of file, if that is all you need.

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

But crashtests don't use ini but crashtests.list, no? AFAICT there's no equivalent of schema=https.

Comment 7

[Timothy Nikkel (:tnikkel)]

Oops, I meant the .list file, you just add HTTP to the start of the line.

Comment 8

[Kagami Rosylight [:saschanaz] (they/them)]

Huh, so HTTP load 1771033.html. That works for now, but ideally it should be HTTPS load since this one is supposed to be HTTPS-only (bug 1112134).

Anyway, thanks!

Comment 9

[Kagami Rosylight [:saschanaz] (they/them)]

2d291a99004d (an 2021-06-02 build) also has this, an old enough bug.

Comment 10

[Timothy Nikkel (:tnikkel)]

Probably not too hard to add https support, looks like layout/tools/reftest/manifest.jsm has the parsing support, layout/tools/reftest/reftest.jsm starts the http server. Not sure if there are extra hoops to jump through to get a certificate, but he mochitest http server code can be helpful to look at.

Comment 11

[Kagami Rosylight [:saschanaz] (they/them)]

Cool! But at a second thought, I'll have to add a flag to keep insecure context support to keep existing tests running anyway, so I guess no hurry. Thanks again 👍

Comment 12

[Kagami Rosylight [:saschanaz] (they/them)]

Revisiting some old bugs...

So this happens because dom::cache::Manager is trying to remove a file by DeleteOrphanedBodyAction which is somehow still in use. (QM_TRY reports NS_ERROR_FILE_IS_LOCKED but that's actually from ERROR_SHARING_VIOLATION.) Probably the response cloning is making another user of the file?

The affected file is {...}.final.