Crash in static void webrender::platform::windows::font::FontContext::add_native_font

RESOLVED FIXED in Firefox 66

Status

()

P2
critical
RESOLVED FIXED
11 months ago
2 months ago

People

(Reporter: darkspirit, Assigned: lsalzman)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs, {crash, nightly-community})

Trunk
mozilla66
x86_64
Windows 10
crash, nightly-community
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox-esr60 unaffected, firefox59 unaffected, firefox60 unaffected, firefox61 disabled, firefox62 disabled, firefox63 disabled, firefox64 disabled, firefox65 disabled, firefox66 fixed)

Details

(crash signature)

Attachments

(6 attachments, 1 obsolete attachment)

(Reporter)

Description

11 months ago
New on Socorro.

bp-d1d968eb-220b-435b-b0c2-6054a0180421 build 2018-04-20_220029 Win10
> called `Option::unwrap()` on a `None` value
Blocks: 1386669
Priority: -- → P1
(Reporter)

Updated

11 months ago
See Also: → bug 1455743
The crash stack is not that useful. I tried loading the minidump in windbg and visual studio and neither gave me the needed additional information.
This will hopefully be elaborated by https://github.com/servo/webrender/pull/2699
(Reporter)

Updated

11 months ago
Depends on: 1457241
The most recent crashes [1] have this:

MOZ_CRASH Reason: missing descriptor FontDescriptor { family_name: "Arial", weight: Regular, stretch: Normal, style: Normal }

[1] https://crash-stats.mozilla.com/report/index/f67005ab-c339-4950-be37-77d470180523. There's three others on the same date/buildid, probably from the same person. In fact I suspect all 7 crashes are probably from the same person, who for some reason is missing the Arial font on their system.
low volume crasher, move to wr-next for now
Blocks: 1386674
No longer blocks: 1386669
Priority: P1 → P3
(Reporter)

Comment 6

6 months ago
AMD, Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X]
bp-b8459e49-e5dd-455b-a64c-3a3780180914.
> missing descriptor FontDescriptor { family_name: "Segoe UI", weight: Regular, stretch: Normal, style: Normal }
Crash Signature: [@ static void webrender::platform::windows::font::FontContext::add_native_font ] → [@ static void webrender::platform::windows::font::FontContext::add_native_font ] [@ webrender::platform::windows::font::FontContext::add_native_font ]
status-firefox62: --- → disabled
status-firefox63: --- → disabled
status-firefox64: --- → affected
Volume for this is relatively high right now.
Blocks: 1386669
No longer blocks: 1386674
Priority: P3 → P2
Lee, any guesses?
Flags: needinfo?(lsalzman)
(Assignee)

Comment 9

6 months ago
We validate in the content process that the font can actually be loaded by descriptor before we send it over. So theoretically this problem should not occur.

Jonathan, is the sandbox somehow getting in the way here?
Flags: needinfo?(lsalzman) → needinfo?(jfkthame)
Maybe it's worth temporarily copying the implementation of get_font_family_by_name() into webrender to see which branch is causing the error.
(In reply to Lee Salzman [:lsalzman] from comment #9)
> We validate in the content process that the font can actually be loaded by
> descriptor before we send it over. So theoretically this problem should not
> occur.
> 
> Jonathan, is the sandbox somehow getting in the way here?

I don't know much (anything, really) about the sandbox, sorry. It seems unlikely to be the problem, though: if the sandbox prevented the graphics process using standard system fonts, I expect we'd be seeing this all over the place.

The first couple I looked at were startup crashes (uptime = 0s or 1s), and I wondered if this meant dwrote::FontCollection::system() might have failed to get the system font collection altogether. But there are also crashes with much longer uptimes, like https://crash-stats.mozilla.com/report/index/7d163ba2-2e00-454d-86f4-aba2f0181008 (over 5 hours), so that doesn't seem to be the case.
Flags: needinfo?(jfkthame)
(Reporter)

Updated

5 months ago
Depends on: 1499786
We're hitting "panic!("missing font family for descriptor {:?}", font_handle)"
This suggests that FindFamilyName is failing.
(Assignee)

Comment 15

5 months ago
This adds an extra step of validation to ensure that the family name we queried actually can be used to locate a family in the system font collection. Not totally sure this will fix the issue, but if this patch doesn't fix the issue, then we can at least rule out that being the cause.
Assignee: nobody → lsalzman
Status: NEW → ASSIGNED
Attachment #9022825 - Flags: review?(jfkthame)
Comment on attachment 9022825 [details] [diff] [review]
ensure WR DWrite font descriptors can be found in the system font collection

Review of attachment 9022825 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah, seems worth a try; I think one extra tweak to ensure consistency would be good, though:

::: gfx/2d/Factory.cpp
@@ +970,5 @@
> +  if (FAILED(hr)) {
> +    gfxWarning() << "Failed to create DWrite system font collection";
> +    return nullptr;
> +  }
> +  mDWriteSystemFonts = systemFonts;

This copy of the collection will go out of date if there's a change to the installed fonts while we're running. Gecko handles that (in theory, at least -- I haven't tested lately) by rebuilding the font list in response to the WM_FONTCHANGE message.

So we should probably do something to reset this, too, when such a change happens. Perhaps create a simple ResetDWriteSystemFonts method that clears the cached pointer, and call it from the gfxDWriteFontList version of InitFontListForPlatform().
(Assignee)

Comment 17

5 months ago
v2. This centralizes the GetSystemFontCollection handling into the Moz2D factory, so that when thebes forces the font collection to update, any other users will get an updated version too.
Attachment #9022825 - Attachment is obsolete: true
Attachment #9022825 - Flags: review?(jfkthame)
Attachment #9023002 - Flags: review?(jfkthame)
Comment on attachment 9023002 [details] [diff] [review]
ensure WR DWrite font descriptors can be found in the system font collection

Review of attachment 9023002 [details] [diff] [review]:
-----------------------------------------------------------------

Looks reasonable. One suggested tweak, unless there's some reason it won't work...

::: gfx/2d/Factory.cpp
@@ +954,5 @@
>  
> +RefPtr<IDWriteFontCollection>
> +Factory::GetDWriteSystemFonts(bool aUpdate)
> +{
> +  StaticMutexAutoLock lock(mDeviceLock);

It looks like this could be moved later? If we put it just before the call to GetSystemFontCollection, we'll avoid the cost of locking in the (common) case where we're just returning the cached value.
Attachment #9023002 - Flags: review?(jfkthame) → review+
(Assignee)

Updated

5 months ago
Keywords: leave-open

Comment 19

5 months ago
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f62458d789a5
ensure WR DWrite font descriptors can be found in the system font collection. r=jfkthame
Depends on: 1506058
(Assignee)

Comment 21

4 months ago
WR PR https://github.com/servo/webrender/pull/3364 is another experimental change to see if it is just that the system font collection is not get updated on the WR process for some reason.
(Assignee)

Updated

4 months ago
Depends on: 1510592
Depends on: 1510884
No longer depends on: 1510592
Did pr 3364 help?
Flags: needinfo?(lsalzman)
(Assignee)

Comment 23

4 months ago
There do not appear to have been any crashes in builds since the last change. This would imply the problem is the system font collection in the WR process simply did not update as quickly as it did in the content process. The forced updating of the system font collection in the WR font process seems to have resolved this. I will mark this as fixed for now, and if it still happens we can reopen it and continue investigating.
Flags: needinfo?(lsalzman)
(Assignee)

Updated

4 months ago
Status: ASSIGNED → RESOLVED
Last Resolved: 4 months ago
Keywords: leave-open
Resolution: --- → FIXED
(Reporter)

Updated

4 months ago
See Also: → bug 1512971
(Assignee)

Updated

4 months ago
Status: RESOLVED → REOPENED
Crash Signature: [@ static void webrender::platform::windows::font::FontContext::add_native_font ] [@ webrender::platform::windows::font::FontContext::add_native_font ] → [@ static void webrender::platform::windows::font::FontContext::add_native_font ] [@ webrender::platform::windows::font::FontContext::add_native_font ] [@ core::result::unwrap_failed<T> | webrender::platform::windows::font::FontContext::add_native_font ]
Resolution: FIXED → ---
(Assignee)

Updated

4 months ago
Duplicate of this bug: 1512971
(Assignee)

Comment 25

3 months ago
This code is ugly but is meant to be ripped out as soon as we get feedback about what is causing the errors. 

Normally WR font resource updates have a format that is fixed by webrender_api (dwrote::FontDescriptor), and I didn't want to introduce a temporary breaking webrender_api change just for this that would break other users of WR like Servo. To workaround this, I just made a separate IPDL hook that gets triggered before the font is added, so that we avoid having to mess with the WR libraries themselves.

On the content/sending side, it just retrieves a list of files and verifies that they are all accessible. On the WR/receiving side it takes the list of files and verifies they are all accessible, and also that the font family is available. If neither of those happens to be true, it spews some critical notes to the gfx log that should be visible in the crash information that will ideally happen shortly after.
Attachment #9030564 - Flags: review?(jmuizelaar)
(Assignee)

Updated

3 months ago
Keywords: leave-open
Attachment #9030564 - Flags: review?(jmuizelaar) → review+

Comment 26

3 months ago
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/26dc4b7babf3
validate access to DWrite font files in WR and output helpful log messages on failure. r=jrmuizel

Comment 27

3 months ago
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2d578724b2e5
fix logging of wchar strings on MinGW builds. r=me
(Reporter)

Updated

3 months ago
See Also: → bug 1514810
(Assignee)

Comment 30

3 months ago
We haven't seen crashes since I added the debugging/validation code, so I wonder if we were exiting early from GetWRFontDescriptor. This fixes all that up to let GetWRFontDescriptor proceed anyway so that we can still crash as always, while leaving yet more critical notes in the log to let us know if we would have in fact short-circuited the crash in the validation code previously.
Attachment #9032079 - Flags: review?(jmuizelaar)
Attachment #9032079 - Flags: review?(jmuizelaar) → review+

Comment 31

3 months ago
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5839c234ceba
let UnscaledFontDWrite::GetWRFontDescriptor continue even if retrieving file names fails. r=jrmuizel

Comment 33

3 months ago
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8c39d7d39ea5
output useful information about font file attributes with error. r=me

I had a look at some of the crash reports for this and it struck me that generally they seem to come in fours, which is down to the three retries for the GPU process.
The first one is often a fairly normal up-time, with the other three short or very short.
So, it seemed that things were going swimmingly until the first crash, then it couldn't recover.

It seemed unlikely that this would be down to a web page, especially given some of the URLs in the crashes.

So I thought, what about the default font and hit upon the following STR that seem to give the same crashes:

  • Install a custom font (I installed Liberation Sans, because it was in one of the crashes and free. I used the Bold Italic face just to make it stand out.)
  • Start Firefox with webrender enabled.
  • Navigate to about:preferences and select Liberation Sans as the Default font.
  • Open a new tab and navigate to "data:text/html,Hello World!" ... Liberation Sans will be used.
  • In Windows Explorer go to C:\Windows\Fonts and delete the Liberation Sans font.
  • Back in Firefox, open another new tab and navigate to "data:text/html,Hello World!" again ... kaboom!
    (You might have to try and switch tabs to cause the subsequent crashes.)

Looks like when we react to the font deletion at [1], we don't check to see if any of the font prefs still exist.
I guess we should switch back to the default if it doesn't and possibly we need to notify each child of the change.

Also, if you install the new font while Firefox is running the Default font list gets updated, but it doesn't seem to get removed when you delete the font (until restart).

[1] https://searchfox.org/mozilla-central/rev/7adb490485eff0783071a3e132005bceeb337461/widget/windows/nsWindow.cpp#5011

(In reply to Bob Owen (:bobowen) from comment #35)

I had a look at some of the crash reports for this and it struck me that generally they seem to come in fours, which is down to the three retries for the GPU process.
The first one is often a fairly normal up-time, with the other three short or very short.
So, it seemed that things were going swimmingly until the first crash, then it couldn't recover.

It seemed unlikely that this would be down to a web page, especially given some of the URLs in the crashes.

So I thought, what about the default font and hit upon the following STR that seem to give the same crashes:

  • Install a custom font (I installed Liberation Sans, because it was in one of the crashes and free. I used the Bold Italic face just to make it stand out.)
  • Start Firefox with webrender enabled.
  • Navigate to about:preferences and select Liberation Sans as the Default font.
  • Open a new tab and navigate to "data:text/html,Hello World!" ... Liberation Sans will be used.
  • In Windows Explorer go to C:\Windows\Fonts and delete the Liberation Sans font.
  • Back in Firefox, open another new tab and navigate to "data:text/html,Hello World!" again ... kaboom!
    (You might have to try and switch tabs to cause the subsequent crashes.)

Looks like when we react to the font deletion at [1], we don't check to see if any of the font prefs still exist.
I guess we should switch back to the default if it doesn't and possibly we need to notify each child of the change.

Also, if you install the new font while Firefox is running the Default font list gets updated, but it doesn't seem to get removed when you delete the font (until restart).

[1] https://searchfox.org/mozilla-central/rev/7adb490485eff0783071a3e132005bceeb337461/widget/windows/nsWindow.cpp#5011

This is quite similar to some STR that I found while talking to Lee (on IRC) a couple days ago; copying a log excerpt here:

Jan 09 21:30:25 <jfkthame> ha! i just reproduced what looks very much like one of these
Jan 09 21:30:31 <jfkthame> take a look at https://crash-stats.mozilla.com/report/index/8665d2c2-227b-48c9-a5fc-1f0f90190109
Jan 09 21:31:31 <jfkthame> what i did: loaded a simple doc using a Source Sans Pro font, then (while the browser was running) uninstalled the font, then tried to load the same doc into a new tab
Jan 09 21:32:43 <jfkthame> this gives me an error "MISSING font family "Source Sans Pro" has INVALID(0xffffffff) file"
Jan 09 21:36:12 <jfkthame> it seemed to crash and restart the graphics process several times in quick succession, which matches the crash reports i looked at (they seem to come in groups of about 3-4 from the same installation), then webrender gets disabled and it settles down
Jan 09 21:36:43 <lsalzman> that one makes little sense because we check before sending if the file is around
Jan 09 21:36:51 <lsalzman> and there's nothing in the logs saying it's not :/
Jan 09 21:37:06 <jfkthame> the content process that was already using it seems to still have access
Jan 09 21:37:12 <jfkthame> but new content processes can't see it
Jan 09 21:38:40 <jfkthame> i see a message "sending font family "Source Sans Pro" with invalid file..." in about:support
Jan 09 21:38:50 <jfkthame> that sounds like it's coming from the content-process side(?)
Jan 09 21:39:25 <jfkthame> then it's followed by the MISSING font family... message from webrender
Jan 09 21:40:03 <lsalzman> https://searchfox.org/mozilla-central/source/gfx/2d/ScaledFontDWrite.cpp#347
Jan 09 21:40:22 <lsalzman> i check that GetFileAttributes succeeds before sending it over
Jan 09 21:41:03 <jfkthame> well, no... if attribs == INVALID, it logs a gfxCriticalNote but doesn't seem to bail out?
Jan 09 21:41:22 <lsalzman> yeah
Jan 09 21:41:27 <lsalzman> the critical note is just supposed to show up in the log
Jan 09 21:41:31 <lsalzman> so it should be there
Jan 09 21:41:41 <lsalzman> locally, can you see if the critical note is getting triggered but not showing up in the report?
Jan 09 21:42:03 <jfkthame> the critical note shows up in the Failure Log section of about:support
Jan 09 21:42:31 <lsalzman> and it says something like "sending font family with invalid file"?
Jan 09 21:42:38 <jfkthame> yep
Jan 09 21:42:50 <jfkthame> which sounds like it's heading for trouble
Jan 09 21:43:11 <lsalzman> okay, so at least this case is discernible
Jan 09 21:43:25 <lsalzman> any way to see that in the crash report itself?
Jan 09 21:45:06 <jfkthame> not that i can see, it only shows the most recent note, which is the MISSING one from the WR side
Jan 09 21:45:16 <lsalzman> hmm
Jan 09 21:45:22 <lsalzman> well, that still leaves the other reports
Jan 09 21:45:28 <lsalzman> which show the files as valid
Jan 09 21:45:45 <jfkthame> yeah, don't yet know how to trigger that
Jan 09 21:45:47 <lsalzman> the segoe ui historic and meiryo ones
Jan 09 21:46:03 <lsalzman> so we can at least fix the source sans pro case
Jan 09 21:46:36 <lsalzman> but i don't think those are related to installation or removal, because those two fonts are defaults, right?
Jan 09 21:47:32 <jfkthame> segoe ui historic should be, i believe meiryo is only present if an additional japanese fonts package is installed

Note that this version of the STR does not depend on tweaking default font settings at all; instead, I loaded a document (just a trivial data: URI) that explicitly called for a user-installed font, then deleted that font while the browser was running.

Also note that this may not adequately explain all the crash reports, though it does look like it may account for some of them. But in some cases the reports show a font like Segoe UI Historic that is installed as standard, and I don't think Windows even lets the user remove it.

(Assignee)

Comment 38

2 months ago

Depends on D16896

Comment 40

2 months ago
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/23e27b3097c6
use paths for WR font handles on Windows r=jrmuizel
https://hg.mozilla.org/integration/autoland/rev/b7a0887937f4
update dwrote to version 0.8 r=jrmuizel
https://hg.mozilla.org/integration/autoland/rev/424203c9c430
implement shared cache of dwrote font files r=jrmuizel
(Assignee)

Updated

2 months ago
Flags: needinfo?(lsalzman)

Comment 42

2 months ago
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b8444f241aca
use paths for WR font handles on Windows. r=jrmuizel
https://hg.mozilla.org/integration/mozilla-inbound/rev/44a36f0fe512
update dwrote to version 0.8. r=jrmuizel
https://hg.mozilla.org/integration/mozilla-inbound/rev/f2279ecacb81
implement shared cache of dwrote font files. r=jrmuizel

Comment 43

2 months ago
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/d56504db04ea
fix wrench font_key_from_name parameter order. r=me CLOSED TREE

Comment 44

2 months ago

Backed out for windows wrench failures.

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&revision=d56504db04eae60a686340716dd8e5b95eae31f1&selectedJob=223595700

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=223595700&repo=mozilla-inbound&lineNumber=2122

[task 2019-01-23T22:48:11.836Z] error[E0507]: cannot move out of borrowed content
[task 2019-01-23T22:48:11.836Z] --> webrender\src\platform\windows\font.rs:605:61
[task 2019-01-23T22:48:11.836Z] |
[task 2019-01-23T22:48:11.836Z] 605 | if let Some(file) = dwrote::FontFile::new_from_path(font_handle.0.path) {
[task 2019-01-23T22:48:11.836Z] | ^^^^^^^^^^^^^ cannot move out of borrowed content
[task 2019-01-23T22:48:11.836Z]
[task 2019-01-23T22:48:12.241Z] error: aborting due to previous error
[task 2019-01-23T22:48:12.241Z]
[task 2019-01-23T22:48:12.241Z] For more information about this error, try rustc --explain E0507.
[task 2019-01-23T22:48:12.347Z] error: Could not compile webrender.
[task 2019-01-23T22:48:12.347Z]
[task 2019-01-23T22:48:12.347Z] Caused by:
[task 2019-01-23T22:48:12.347Z] process didn't exit successfully: rustc --crate-name webrender webrender\src\lib.rs --color never --crate-type lib --emit=dep-info,metadata -C debuginfo=2 --cfg "feature=\"pathfinder\"" --cfg "feature=\"pathfinder_font_renderer\"" --cfg "feature=\"pathfinder_gfx_utils\"" --cfg "feature=\"pathfinder_partitioner\"" --cfg "feature=\"pathfinder_path_utils\"" -C metadata=8b3e83a7199988e0 -C extra-filename=-8b3e83a7199988e0 --out-dir z:\task_1548280440\build\src\gfx\wr\target\debug\deps -C incremental=z:\task_1548280440\build\src\gfx\wr\target\debug\incremental -L dependency=z:\task_1548280440\build\src\gfx\wr\target\debug\deps --extern app_units=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libapp_units-cb5e3b8243b9b32f.rmeta --extern bincode=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libbincode-db136ed51b6e47f1.rmeta --extern bitflags=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libbitflags-87a0fa3ff0eb5c67.rmeta --extern byteorder=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libbyteorder-946e9fd62250fa8b.rmeta --extern cfg_if=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libcfg_if-a3f589c77c6f36bc.rmeta --extern dwrote=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libdwrote-170717bd3a516ebc.rmeta --extern fxhash=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libfxhash-b132b067ace5ba32.rmeta --extern gleam=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libgleam-a9de2a78251f2c9e.rmeta --extern lazy_static=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\liblazy_static-6e6877f06d35d674.rmeta --extern log=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\liblog-39a8e1d0ca8d1387.rmeta --extern malloc_size_of_derive=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\malloc_size_of_derive-cc21299d15721191.dll --extern num_traits=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libnum_traits-6233947f952b2bba.rmeta --extern pathfinder_font_renderer=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libpathfinder_font_renderer-efbeb7264df42756.rmeta --extern pathfinder_gfx_utils=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libpathfinder_gfx_utils-ae8b7c7a25e22d18.rmeta --extern pathfinder_partitioner=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libpathfinder_partitioner-c4b3925d3bd39d2f.rmeta --extern pathfinder_path_utils=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libpathfinder_path_utils-74bf2a8ac1acf116.rmeta --extern plane_split=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libplane_split-68d72cad39703807.rmeta --extern rayon=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\librayon-36f68420381ec490.rmeta --extern sha2=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libsha2-43776b804526757f.rmeta --extern smallvec=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libsmallvec-fdbf32933d5f41cb.rmeta --extern thread_profiler=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libthread_profiler-54c3c18c80c2e5ff.rmeta --extern time=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libtime-9faac3142762e2bf.rmeta --extern webrender_api=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libwebrender_api-aa507491711d9449.rmeta --extern webrender_build=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libwebrender_build-61dd3a28187540cd.rmeta --extern wr_malloc_size_of=z:\task_1548280440\build\src\gfx\wr\target\debug\deps\libwr_malloc_size_of-ff27ee2934ae249d.rmeta --deny warnings -L native=z:\task_1548280440\build\src\gfx\wr\target\debug\build\servo-freetype-sys-7e35a056a122344b\out/lib (exit code: 1)
[task 2019-01-23T22:48:12.353Z]
[task 2019-01-23T22:48:12.353Z] z:\task_1548280440\build\src\gfx\wr\webrender>if 101 NEQ 0 EXIT /b 101
[taskcluster 2019-01-23T22:48:12.612Z] Exit Code: 101
[taskcluster 2019-01-23T22:48:12.612Z] User Time: 0s
[taskcluster 2019-01-23T22:48:12.612Z] Kernel Time: 0s
[taskcluster 2019-01-23T22:48:12.612Z] Wall Time: 40m46.6135694s
[taskcluster 2019-01-23T22:48:12.612Z] Result: FAILED
[taskcluster 2019-01-23T22:48:12.612Z] === Task Finished ===
[taskcluster 2019-01-23T22:48:12.612Z] Task Duration: 40m46.6145539s
[taskcluster 2019-01-23T22:48:13.446Z] Uploading redirect artifact public/logs/live.log to URL https://queue.taskcluster.net/v1/task/eLLpyhVuSyyDrP-4KOh-SA/runs/0/artifacts/public/logs/live_backing.log with mime type "text/plain; charset=utf-8" and expiry 2020-01-23T22:06:57.607Z
[taskcluster:error] exit status 101

Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/a237a1078ce34f063400b3ec9beff1a692d8dbdb

Flags: needinfo?(lsalzman)

Comment 45

2 months ago
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/60a53bfecdae
use paths for WR font handles on Windows. r=jrmuizel
https://hg.mozilla.org/integration/mozilla-inbound/rev/4a57b65dc4f1
update dwrote to version 0.8. r=jrmuizel
https://hg.mozilla.org/integration/mozilla-inbound/rev/3c0c1dc9ae8b
implement shared cache of dwrote font files. r=jrmuizel
(Assignee)

Updated

2 months ago
Flags: needinfo?(lsalzman)

This seems fixed, or at least the volume is low enough that we can not block on it.

Status: REOPENED → RESOLVED
Last Resolved: 4 months ago2 months ago
Resolution: --- → FIXED
status-firefox64: affected → disabled
status-firefox65: --- → disabled
status-firefox66: --- → fixed
Target Milestone: --- → mozilla66
Keywords: leave-open
You need to log in before you can comment on or make changes to this bug.