1468303 - Crash occurs on https://www.prototypo.io/ fonts site

Status: RESOLVED WORKSFORME

(Core :: Graphics: Text, defect, P3)

Description

[Rares Doghi, Desktop QA]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID:20180419224145

[Affected versions]:
Nightly 62.0a1

[Affected platforms]:
Windows 10 X64

1.Launch Nightly 62.0a1 with a new profile
2.Set gfx.downloadable_fonts.otl_validation =False
3.Restart FF
4.Open https://www.prototypo.io/
5. Scroll the page from top to bottom and back up a few times, also play with the fonts customization.

[Expected result]:
The page should be displayed correctly

[Actual result]:
Crash:

https://crash-stats.mozilla.com/report/index/3255fbf1-e8f1-4a2b-8f4f-d57530180612

Please note that i only managed to reproduce this issue on a single machine with windows 10 version : 1709( OS Build 16299.371) i tried different Operating systems and different machines with the same operating system as this one and the issue does not reproduce there either.

Comment 1

[Rares Doghi, Desktop QA]

Please note that it might be related to Bug 886593.

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

There's no layout bits on the stack, so it's more likely a graphics issue.

If you cannot reproduce this on other machines, maybe there is some problem with your DirectX configuration / installation.

Comment 3

[Ryan Hunt [:rhunt]]

Could you copy and paste the contents of your about:support on the affected machine and OS here?

Does this issue reproduce in release as well, or only just nightly?

Comment 4

[Rares Doghi, Desktop QA]

Attachment: AboutSupport.txt

I have attached the About:Support information to this issue from the Windows 10 x64 machine

Comment 5

[Rares Doghi, Desktop QA]

I reproduced this issue on all versions of Firefox.

Comment 6

[Rares Doghi, Desktop QA]

Another Side Note, i also have Ubuntu 18.04 on the same machine and i cant reproduce the crash, i could only reproduce it on that Windows 10.

Comment 7

[Andrew Osmond [:aosmond] (he/him)]

This appears to have been around for a long time since we see it in 52esr, but it still happens today on nightly. Seems agnostic of Windows version and hardware. I could only get correlations for esr, but nothing jumps out at me.

Comment 8

[Lee Salzman [:lsalzman]]

Talking to Jonathan Kew, this appears to be a crash deep in DWrite itself due to a bug in DWrite's rasterzation code. However, merely forcing the otl_validation pref to true would seem to not be a viable option here as it would cause too many renderable fonts to no longer show up as collateral damage. It is not clear how to proceed at present.

Comment 9

[Bob Clary [:bc] (inactive)]

Bughunter found this reproducible crash.

1. https://walletinvestor.com/stock-forecast/verb-stock-prediction
2. Crash Windows Opt builds. Assert in various ways in debug builds. May need to wait a little bit but not for long.

Firefox 70.0.1 Did not crash
Firefox 72.0.1 Crash Report [@ dotProduct ] bp-8efd9b3a-daf9-4409-aa6c-84c4a0200113
Firefox 73.0a1 Crash Report [@ dotProduct ] bp-e84f40cb-7407-45f8-abf0-4c1580200113
Firefox 74.0a1 Crash Report [@ dotProduct ] bp-5978f2c0-87ab-4fb3-b520-ec0a60200113

This may not be the same bug since 70 didn't crash outright but commenting here for now.

Comment 10

[Jonathan Kew [:jfkthame]]

Assert in various ways in debug builds

Could you provide a log of the assertions you get? Thanks.

Comment 11

[Bob Clary [:bc] (inactive)]

Attachment: Full log for Assertion failure: mUsage == 0

Bughunter reproduced the following

Assertion failure: mUsage == 0, at z:/build/build/src/dom/localstorage/ActorsParent.cpp:5538
JavaScript error: C:/mozilla/builds/hg.mozilla.org/sisyphus/python/sisyphus/automation/runner.py, line 310: ReferenceError: ChromeWindow is not defined
[Parent 6396, Main Thread] WARNING: IPC message discarded: actor cannot send: file z:/build/build/src/ipc/glue/ProtocolUtils.cpp, line 481
#01: mozilla::dom::`anonymous namespace'::Connection::CloseOp::Cleanup() [dom/localstorage/ActorsParent.cpp:4710]
#02: mozilla::dom::`anonymous namespace'::ConnectionDatastoreOperationBase::Run() [dom/localstorage/ActorsParent.cpp:4097]
#03: nsThread::ProcessNextEvent(bool, bool*) [xpcom/threads/nsThread.cpp:1249]
#04: NS_ProcessNextEvent(nsIThread*, bool) [xpcom/threads/nsThreadUtils.cpp:486]
#05: mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) [ipc/glue/MessagePump.cpp:332]
#06: MessageLoop::RunHandler() [ipc/chromium/src/base/message_loop.cc:309]
#07: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:291]
#08: static nsThread::ThreadFunc(void*) [xpcom/threads/nsThread.cpp:467]
#09: PR_NativeRunThread(void*) [nsprpub/pr/src/threads/combined/pruthr.c:408]
#10: pr_root(void*) [nsprpub/pr/src/md/windows/w95thred.c:140]
#11: ucrtbase.dll + 0x20e72
#12: KERNEL32.DLL + 0x17bd4
#13: ntdll.dll + 0x6ced1

Comment 12

[Bob Clary [:bc] (inactive)]

Attachment: Debug crash log

When I attempted to reproduce on the vm, I started hitting MOZ_CRASH("NSS_Shutdown failed") but I can't reproduce that at the moment though my debug build still crashes. I've attached a log where I crashed several times and reloaded only to crash again without reproducing the assertion failure I was looking for originally or the MOZ_CRASH("NSS_Shutdown failed").

Comment 13

[Jonathan Kew [:jfkthame]]

Hmm - ok, it looks like the assertion in comment 11 is unlikely to be related to the DirectWrite crash.

Comment 14

[Wayne Mery (:wsmwk)]

Reporter, does this still reproduce for you?

Comment 15

[Rares Doghi, Desktop QA]

Unfortunately the website where this issue occured no longer works and the operating system has performed many updates since then, I think we can close this issue as Works for me for now and reopen it if it starts to occurs on other machines, but since the Website no longer works we can just open new issues with the new Website.

Comment 16

[Jonathan Kew [:jfkthame]]

All the recent-ish crash reports I see with the [@ dotProduct] signature look like the kind of DirectWrite exceptions due to hardware issues that we have recently tried to handle better, so that may help; but the original report here may have been something different anyhow, as it looks like it involved a webfont. But with the site gone, there's nothing to investigate further for now.

Closing as WFM per comment 15.