Closed
Bug 1335308
Opened 8 years ago
Closed 8 years ago
stylo: Add some assertions to document our invariants and aid the static analysis
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
mozilla54
Tracking | Status | |
---|---|---|
firefox54 | --- | fixed |
People
(Reporter: bholley, Unassigned)
References
Details
Attachments
(5 files, 1 obsolete file)
1.15 KB,
patch
|
emilio
:
review+
|
Details | Diff | Splinter Review |
943 bytes,
patch
|
emilio
:
review+
|
Details | Diff | Splinter Review |
2.85 KB,
patch
|
heycam
:
review+
|
Details | Diff | Splinter Review |
1.10 KB,
patch
|
emilio
:
review+
|
Details | Diff | Splinter Review |
2.86 KB,
patch
|
heycam
:
review+
|
Details | Diff | Splinter Review |
No description provided.
Reporter | ||
Comment 1•8 years ago
|
||
Attachment #8831941 -
Flags: review?(emilio+bugs)
Reporter | ||
Comment 2•8 years ago
|
||
Brian, what's the correct annotation to add for the static analysis?
Attachment #8831942 -
Flags: review?(emilio+bugs)
Attachment #8831942 -
Flags: feedback?(bhackett1024)
Updated•8 years ago
|
Attachment #8831941 -
Flags: review?(emilio+bugs) → review+
Updated•8 years ago
|
Attachment #8831942 -
Flags: review?(emilio+bugs) → review+
Comment 3•8 years ago
|
||
Comment on attachment 8831942 [details] [diff] [review]
Part 2 - Assert against non-length units in Gecko_CSSValue_SetAbsoluteLength. v1
Review of attachment 8831942 [details] [diff] [review]:
-----------------------------------------------------------------
Handling this in the static analysis would be kind of hard. It would be difficult to train the static analysis to understand properties of CSS values and how that affects control flow as it explores the stack. Using an annotation would work, but it would be rather fragile --- something like "ignore calls to nsCSSValue::DoReset when Gecko_CSSValue_SetAbsoluteLength is on the stack". Allowing annotations to inspect the stack is problematic for soundness of the analysis (i.e. conservatively determining the program's possible behaviors), because we don't necessarily reanalyze functions if we find multiple different stacks that reach them.
The best way to teach the static analysis is to add assertions for either NS_IsMainThread or for the flag that is added in bug 1335319 along paths which should not execute during a parallel traversal. In this case that would be in the various ->Release() calls in nsCSSValue::DoReset I think, though maybe there is a better pinchpoint that doesn't clutter up the code as much.
Attachment #8831942 -
Flags: feedback?(bhackett1024)
Reporter | ||
Comment 4•8 years ago
|
||
Attachment #8833033 -
Flags: review?(cam)
Reporter | ||
Comment 5•8 years ago
|
||
We'll need to deal with this at some point, but let's just forbid it for now
to appease the static analysis.
Attachment #8833106 -
Flags: review?(emilio+bugs)
Comment 6•8 years ago
|
||
Comment on attachment 8833033 [details] [diff] [review]
Part 3 - Assert against releasing refcounted nsCSSValue members off-main-thread. v1
Review of attachment 8833033 [details] [diff] [review]:
-----------------------------------------------------------------
mURL and mImage do have thread-safe refcounts, but that's probably beside the point.
When do we actually call Reset() on an nsCSSValue that is not already eCSSUnit_Null, from style worker threads? If we don't, it might be easier just to do:
if (mUnit == eCSSUnit_Null) {
return;
}
MOZ_ASSERT(NS_IsMainThread());
at the top of DoReset instead.
Attachment #8833033 -
Flags: review?(cam) → review+
Updated•8 years ago
|
Attachment #8833106 -
Flags: review?(emilio+bugs) → review+
Reporter | ||
Comment 7•8 years ago
|
||
(In reply to Cameron McCormack (:heycam) from comment #6)
> Comment on attachment 8833033 [details] [diff] [review]
> Part 3 - Assert against releasing refcounted nsCSSValue members
> off-main-thread. v1
>
> Review of attachment 8833033 [details] [diff] [review]:
> -----------------------------------------------------------------
>
> mURL and mImage do have thread-safe refcounts, but that's probably beside
> the point.
>
> When do we actually call Reset() on an nsCSSValue that is not already
> eCSSUnit_Null, from style worker threads? If we don't, it might be easier
> just to do:
>
> if (mUnit == eCSSUnit_Null) {
> return;
> }
>
> MOZ_ASSERT(NS_IsMainThread());
>
> at the top of DoReset instead.
I took emilio's comment in bug 1294915 comment 34 to imply that we called it for values that already had a length in it.
Comment 8•8 years ago
|
||
(In reply to Bobby Holley (:bholley) (busy with Stylo) from comment #7)
> (In reply to Cameron McCormack (:heycam) from comment #6)
> > Comment on attachment 8833033 [details] [diff] [review]
> > Part 3 - Assert against releasing refcounted nsCSSValue members
> > off-main-thread. v1
> >
> > Review of attachment 8833033 [details] [diff] [review]:
> > -----------------------------------------------------------------
> >
> > mURL and mImage do have thread-safe refcounts, but that's probably beside
> > the point.
> >
> > When do we actually call Reset() on an nsCSSValue that is not already
> > eCSSUnit_Null, from style worker threads? If we don't, it might be easier
> > just to do:
> >
> > if (mUnit == eCSSUnit_Null) {
> > return;
> > }
> >
> > MOZ_ASSERT(NS_IsMainThread());
> >
> > at the top of DoReset instead.
>
> I took emilio's comment in bug 1294915 comment 34 to imply that we called it
> for values that already had a length in it.
I believe we can destruct a length nsCSSValue if we explicitly inherit transform, then reset it with another rule, but I could be wrong given I haven't followed all the transform business lately.
Reporter | ||
Comment 9•8 years ago
|
||
This isn't really an assertion, but goes with part 3.
Attachment #8834730 -
Flags: review?(cam)
Updated•8 years ago
|
Attachment #8834730 -
Flags: review?(cam) → review+
Reporter | ||
Comment 10•8 years ago
|
||
Attachment #8834758 -
Flags: review?(cam)
Reporter | ||
Updated•8 years ago
|
Attachment #8834730 -
Attachment is obsolete: true
Comment 11•8 years ago
|
||
Comment on attachment 8834758 [details] [diff] [review]
Part 5 - Proxy mSpecifiedTransform releases that occur during the servo traversal to the main thread. v2
Review of attachment 8834758 [details] [diff] [review]:
-----------------------------------------------------------------
I get slightly nervous when I see behaviour changes between debug and non-debug builds, though I guess it's self contained enough here that I don't need to worry.
Attachment #8834758 -
Flags: review?(cam) → review+
Reporter | ||
Comment 12•8 years ago
|
||
Reporter | ||
Comment 13•8 years ago
|
||
Comment 14•8 years ago
|
||
Pushed by bholley@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f15fdc620527
Assert main thread in Gecko_LoadStyleSheet. r=emilio
https://hg.mozilla.org/integration/mozilla-inbound/rev/ee7bdede91b6
Assert against non-length units in Gecko_CSSValue_SetAbsoluteLength. r=emilio
https://hg.mozilla.org/integration/mozilla-inbound/rev/9d10905855f9
Assert against releasing refcounted nsCSSValue members off-main-thread. r=heycam
https://hg.mozilla.org/integration/mozilla-inbound/rev/a00867c65c49
Assert against destroying images and counters in generated content off-main-thread. r=emilio
https://hg.mozilla.org/integration/mozilla-inbound/rev/61cd520a0057
Proxy mSpecifiedTransform releases that occur during the servo traversal to the main thread. r=heycam
Comment 15•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/f15fdc620527
https://hg.mozilla.org/mozilla-central/rev/ee7bdede91b6
https://hg.mozilla.org/mozilla-central/rev/9d10905855f9
https://hg.mozilla.org/mozilla-central/rev/a00867c65c49
https://hg.mozilla.org/mozilla-central/rev/61cd520a0057
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox54:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
You need to log in
before you can comment on or make changes to this bug.
Description
•