1303764 - Crash in Abort | LoadSheetSync failed with error 8052000b loading built-in stylesheet 'resourc... | mozalloc_abort | NS_DebugBreak | ErrorLoadingBuiltinSheet

Status: RESOLVED DUPLICATE of bug 315278

(Toolkit :: Application Update, defect, P2)

Description

[Marcia Knous [:marcia]]

This bug was filed from the Socorro interface and is 
report bp-ad8d8018-a938-4887-9128-fa4082160919.
=============================================================

Seen while looking at Nightly crash stats. dbaron's report shows 193 crashes in 20160918030408.

Related or the same as Bug 1303526?

Comment 1

[Trevor Saunders (:tbsaunde)]

no, this looks like what you get when you start firefox with a busted install dir.  moving to layout::style, but that's probably not actually correct.

Comment 2

[Andrew McCreight [:mccr8]]

Bug 1300720 looks similar. Maybe a differently processed signature?

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature 'Abort | LoadSheetSync failed with error 8052000b loading built-in stylesheet 'resourc... | mozalloc_abort | NS_DebugBreak | ErrorLoadingBuiltinSheet':
 - nightly (version 52): 2 crashes from 2016-09-19.
 - aurora  (version 51): 15 crashes from 2016-09-19.
 - beta    (version 50): 110 crashes from 2016-09-20.
 - release (version 49): 126 crashes from 2016-09-05.
 - esr     (version 45): 88 crashes from 2016-06-01.

Crash volume on the last weeks (Week N is from 10-03 to 10-09):
            W. N-1  W. N-2
 - nightly       0       2
 - aurora       15       0
 - beta        105       5
 - release      77      49
 - esr           6      32

Affected platforms: Windows, Linux

Crash rank on the last 7 days:
           Browser     Content   Plugin
 - nightly
 - aurora  #70
 - beta    #138
 - release #612
 - esr     #990

Comment 4

[[:philipp]]

it's hard to say for sure, because the overall numbers are quite small, but it looks like the volume of this signature on beta has risen a bit since the fix for bug 1300720 has landed. 
could those two things be related (as was mentioned in comment #2)?

Comment 5

[[:philipp]]

[Tracking Requested - why for this release]:
nominating this bug for tracking as the signature is the top 5 startup crash during last week for the 50.0b cycle.

Comment 6

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

This signature is at #27 at the moment. I don't feel the need to track this one anymore. If we get a fix, we could uplift to 51+

Comment 7

[Marco Castelluccio [:marco]]

This is coming from a small number of installations on 51.

Comment 8

[Astley Chen (inactive)]

From the latest crash stat, it seems to not happen on Firefox 52. Let's keep tracking.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

There were a smattering of reports for 52 on Nightly/Aurora, but none so far since it went to Beta. No reports on 53/54 yet either. Guess we'll keep it on the radar for now.

Comment 10

[[:philipp]]

the crash seems to have changed signature in 52.0b

Comment 11

[Mats Palmgren (inactive)]

Still occurs in v56: bp-63bad83c-f20a-46bd-83c1-16f310170706
Some error messages are:

xpcom_runtime_abort(###!!! ABORT: LoadSheetSync failed with error 8052000b loading built-in stylesheet 'resource://gre/res/contenteditable.css': file c:/builds/moz2_slave/m-cen-w64-ntly-000000000000000/build/src/layout/style/nsLayoutStylesheetCache.cpp, line 776)

xpcom_runtime_abort(###!!! ABORT: LoadSheetSync failed with error 8052000b loading built-in stylesheet 'resource://gre-resources/counterstyles.css': file c:/builds/moz2_slave/m-cen-w32-ntly-000000000000000/build/src/layout/style/nsLayoutStylesheetCache.cpp, line 776)

where 8052000b means NS_ERROR_FILE_CORRUPTED

Comment 12

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

We recently observed this crash on Mac whenever launching web-platform-test. At least two people encounter this problem. Hsin-yi, Tom can you provide the environment and which CL do you use?

Comment 13

[Tom Tung [:tt, :ttung]]

Sorry, I found my error code is different. Mine is 80520015 and this issue is 8052000b.

But, I'm able to reproduce it every time by running wpt test. I put my log below:

 1:54.08 PROCESS_OUTPUT: ProcessReader (pid:99897) "[Child 99899] ###!!! ABORT: LoadSheetSync failed with error 80520015 loading built-in stylesheet 'resource://gre-resources/counterstyles.css': file /Mozilla/Work/mc/layout/style/nsLayoutStylesheetCache.cpp, line 776"
 1:54.14 PROCESS_OUTPUT: ProcessReader (pid:99897) "#01: ErrorLoadingSheet(nsIURI*, char const*, mozilla::css::FailureAction)[/Mozilla/Work/mc/obj-x86_64-apple-darwin16.6.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x4f7e8d1]"

Comment 14

[Cameron McCormack (:heycam)]

8052000b is NS_ERROR_FILE_ACCESS_DENIED, which sounds like it could be sandbox related, and I wonder if it's related to bug 1380132.

Comment 15

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

I think you mean 80520015 is NS_ERROR_FILE_ACCESS_DENIED. 8052000b = NS_ERROR_FILE_CORRUPTED.

I'm also experiencing 80520015, basically nightly debug refuses to start every time with my profile. With new profile it works.

Comment 16

[Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me)]

I see 80520015 with a start-up crash whenever I run ./mach marionette-test on mac os. (Also with wpt)

Comment 17

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

I also can't run mach marionette-test anymore on osx (I don't see 80520015 as I don't seem to get debug info, but tab appears crashed and I get "IOError: Content process crashed (Reason: Timed out waiting for connection on localhost:2828!)")

Follow-up on comment 15, I'm seeing the problem on startup when debugging nightly debug with XCode (which is how I debug) even on a new profile. Basically, every tab tab-crashes, even the initial one. As a workaround I can open a non-e10s window to debug. Should we open a separate bug perhaps?

Comment 18

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

I've opened Bug 1383214 for the more recent 80520015 (NS_ERROR_FILE_ACCESS_DENIED) error. I'll move there.

Comment 19

[Cameron McCormack (:heycam)]

(In reply to Jan-Ivar Bruaroey [:jib] from comment #15)
> I think you mean 80520015 is NS_ERROR_FILE_ACCESS_DENIED. 8052000b =
> NS_ERROR_FILE_CORRUPTED.

Yes, copy/pasted the wrong number, thanks.

Comment 20

[Panos Astithas (he/him) [:past] (please ni?)]

I don't see any 57 crashes, which is nice.

Comment 21

[Andrew McCreight [:mccr8]]

52% of these crashes have
  LoadSheetSync failed with error 80520012 loading built-in stylesheet 'resource://gre-resources/counterstyles.css'
25% have
  LoadSheetSync failed with error 8052000b loading built-in stylesheet 'resource://gre/res/svg.css'

Comment 22

[Andrew McCreight [:mccr8]]

80520012 is NS_ERROR_FILE_NOT_FOUND
8052000b is NS_ERROR_FILE_CORRUPTED

Comment 24

[Nicholas Nethercote [inactive]]

A single unlucky Mac user has hit this crash dozens of times in Nightly 20171201100115 and 20171201220040.

Comment 25

[Paul Bone [:pbone]]

I'm getting this crash.

My hard disk filled up (of firefox builds) and Firefox crashed, I guess while it was updating this cache.  Now I can't start firefox anymore (unless I use --no-remote).  It is very reproducible (now that I have the corrupted cache) and firefox crashes every single time I start it.  For a non-technical user who hits this by chance it could be very annoying, pushing them away from the browser. (although the chance of filling up the HDD while trying to write this cache is pretty low).

Comment 26

[Paul Bone [:pbone]]

The firefox installation has become corrupt and omni.ja doesn't contain counterstyles.css.  Possibly the disk filled up while an update was being processed.  Is there some way that the browser can provide a friendly error message asking the user to re-install rather than just crashing?

Comment 27

[Liz Henry (:lizzard) (relman/hg->git project)]

This isn't very high volume even on release, so I'm marking this fix-optional for 62. We can still take a patch if anyone takes this on to work on it.

Comment 28

[Mats Palmgren (inactive)]

It appears that many crashes are coming from a few individual installations,
so I think comment 26 is right that the root cause is that the installation
files are corrupt somehow.

This doesn't seem like a style system bug per se, so reassigning to see
if we want to try to repair it somehow...

Comment 29

[Molly Howell (she/her) (no longer active)]

The cause of this problem does seem to be running out of disk space while applying an update, as comment 25 and comment 26 indicate; it's conceivable that an omni.ja could end up being truncated in that case. We have bug 315278 on file for handling that class of failure better, so bug this would appear to be a duplicate of that one.

Comment 30

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late to fix in 63. I don't think keeping this in the regression triage will be useful; it is in the queue as a P2 issue in bug 315278.