1354232 - Enable LeakSanitizer for web-platform-tests

Status: RESOLVED FIXED

(Testing :: web-platform-tests, enhancement)

Description

[Andrew McCreight [:mccr8]]

Once XPCOM leak checking is enabled for web-platform-tests, and AddressSanitizer builds are running them, too, we should make sure the LeakSanitizer is enabled. It catches some kind of low level buffer leaks that the XPCOM leak checker doesn't find.

Comment 1

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Copy LSANLeaks to mozleak,

This is a copy for now rather than a move because followup patches are
going to convert the LSAN support to use mozlog and I don't want to
risk breaking mochitest by accident.

Review commit: https://reviewboard.mozilla.org/r/250300/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250300/

Comment 2

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Add support for LSAN to mozlog,

This adds two new actions to mozlog, one for reporting an LSAN
failure, and one for reporting the summary.

Review commit: https://reviewboard.mozilla.org/r/250302/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250302/

Comment 3

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Ensure lsan failures cause treeherder jobs to fail,

Review commit: https://reviewboard.mozilla.org/r/250304/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250304/

Comment 4

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Enable LSAN Leak detection in wpt,

Review commit: https://reviewboard.mozilla.org/r/250306/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250306/

Comment 5

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Allow wpt manifest files to specify LSAN errors to ignore,

This adds a property lsan-allowed to the expectation manifest files
that takes a list of strings. Any entry in the list that matches a
frame in an LSAN stack will cause that stack to be regarded as an
expected failure.

Review commit: https://reviewboard.mozilla.org/r/250308/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250308/

Comment 6

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Log run-by-dir setting,

Review commit: https://reviewboard.mozilla.org/r/250310/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250310/

Comment 7

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Support skipping output lines in handlers,

Review commit: https://reviewboard.mozilla.org/r/250312/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250312/

Comment 8

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Add group_metadata to test group metadata and pass it through to the browser,

This initially contains a scope entry which is set to the base directory of
the tests being run. Typically this is /, but with run_by_dir, it's the
path to the current run_by_dir group e.g. /html/semantics/form_elements/

Review commit: https://reviewboard.mozilla.org/r/250314/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250314/

Comment 9

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Add support for updating LSAN data in wpt-update

LSAN data differs from existing expectation data because the data is
only generated when the browser exits, so the problems reported can
happen at any point in the current session. We use the `scope`
property in the log message to determine the path to a __dir__.ini
file that covers all the tests run in the session, and add the LSAN
exclusion rules to there.

The rules themselves are generated by taking the topmost frame of any
stack that's reported as unexpectedly leaking, and adding that to the
list of permitted frames in the lsan-allowed property. We never remove
entries from this list since intermittents may be present which won't
appear on a specific run. Instead we rely on humand fixing the issues
to also clean up the expectation files.

Review commit: https://reviewboard.mozilla.org/r/250316/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250316/

Comment 10

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Always try to process the leak log whenever we stop firefox,

The `stop` method is always called to shutdown firefox, but the
cleanup method is only called at the end of a test run. Therefore we
need all the leak processing stuff ot happen in stop().

Review commit: https://reviewboard.mozilla.org/r/250318/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250318/

Comment 11

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Support creating ConditionalValue objects containing a list,

Review commit: https://reviewboard.mozilla.org/r/250320/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250320/

Comment 12

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Support a __dir__.ini file in the metadata root,

Review commit: https://reviewboard.mozilla.org/r/250322/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250322/

Comment 13

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Fix updating assert count when there's an exising value,

In this case we want to take the existing value into account, and update
to 1 more than the new value (in the max-asserts case).

Review commit: https://reviewboard.mozilla.org/r/250324/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250324/

Comment 14

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Refactor data storage in metadata.py,

Previously we were holding a map of test id -> test and test ->
expectation data. But this is an unnecessary layer of indirection, and
it works perfectly well to map test id to the expectation data
directly. This makes the code simpler and may also help make the
update a little faster.

Review commit: https://reviewboard.mozilla.org/r/250326/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250326/

Comment 15

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Fix, enable, and add to, the manifest update tests,

Refactor the tests to make them work with pytest directly rather than
also depending on unittest. Fix the helper functions to work with the
current state of metadata.py. Add some tests for update of assertion
count and lsan data.

Review commit: https://reviewboard.mozilla.org/r/250328/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250328/

Comment 16

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Don't store the result of update_expected,

The needs_human feature never worked well and is unused.

Review commit: https://reviewboard.mozilla.org/r/250330/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250330/

Comment 17

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Run web-platform-tests on linux64-asan,

Review commit: https://reviewboard.mozilla.org/r/250332/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250332/

Comment 18

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Chunk by dir more for wpt on asan,

This means that when we run these tests, the LSAN exceptions will have
the minimum possible scope.

Review commit: https://reviewboard.mozilla.org/r/250334/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250334/

Comment 19

[James Graham [:jgraham]]

Attachment: Bug 1354232 - Update metadata for lsan failures,

Review commit: https://reviewboard.mozilla.org/r/250336/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250336/

Comment 20

[James Graham [:jgraham]]

I just pushed a review for this; I'm not absoutely sure it all works, as I just discovered I forgot to make treeherder/mozharness notice the lsan_* log actions. But particularly given that Maja's going to be away and the code at least nearly works, I think it's ready for review.

The background here is that when we import new web-platform-tests we need a way to ensure that we can make the tree green even though there could be new problems (in this case LSAN) failures. So the approach is to add LSAN to structured logging (via lsan_leak and lsan_summary) actions, and to redirect all the things that can cause failures through there rather than logging strings directly. Then I added the possibility to provide an additional list of stackframes that should cause the leak to be marked as "allowed" (or expected) and added some code in web-platform-tests to update the list of allowed leaks based on the results of a try run. I don't know if there's some better hueristic for picking the best frame from a stack to use as the ignore frame other than just the top one that isn't excluded by the existing exclusions of low-level frames in the LSAN handler.

mccr8 - If this works, how important is the XPCOM leak checking? That works, but probably to enable it I need to repeat the same process of allowing a dynamically updated list of allowed leaks (which is not that hard to do, but of course it's easier to do nothing if LSAN is a pure superset).

Comment 21

[Andrew McCreight [:mccr8]]

Thanks for working on this!

I was going to say that white listing things at the harness level wasn't ideal, but it looks like there are only a handful of failures, and the way that you have them marked looks more finegrained than is available in LSan itself.

Would you like me to file bugs on these leaks? I'm surprised this DNS one shows up in a number of places in WPT, but it isn't a problem elsewhere. It looks like there's only that leak, and some kind of bad worker leak in the file reader directory.

What happens if a leak goes away? Does the list get automatically updated? Also, is there any notification if a new leak shows up?

(In reply to James Graham [:jgraham] from comment #20)
> mccr8 - If this works, how important is the XPCOM leak checking? That works,
> but probably to enable it I need to repeat the same process of allowing a
> dynamically updated list of allowed leaks (which is not that hard to do, but
> of course it's easier to do nothing if LSAN is a pure superset).

We still need XPCOM leak checking because LSan is only run on Linux64. Well, maybe it is run on Windows now, too. LSan will also not report leaks via things held in static variables, while the XPCOM leak checker will.

Comment 22

[Andrew McCreight [:mccr8]]

Also, I'd be interested in a link to a try run, so I could look at what the actual LSan output is for these leaks. Thanks.

Comment 23

[James Graham [:jgraham]]

> What happens if a leak goes away? Does the list get automatically updated? Also, is there any notification if a new leak shows up?

If a leak goes away we don't update the list because of intermittents. That's not ideal, but I don't know what a good solution looks like.

I'll add notification for this in the wpt sync bugs; likely we will extend that to file bugs for specific failures in the second half of this year.

> Also, I'd be interested in a link to a try run, so I could look at what the actual LSan output is for these leaks.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=182fdd5c694a3ad68a9865b2e5a3ab7123761ca6

Is the one I just pushed after fixing the make-the-tree-turn-orange stuff (so hopefully it's orange)

> We still need XPCOM leak checking because LSan is only run on Linux64. Well, maybe it is run on Windows now, too. LSan will also not report leaks via things held in static variables, while the XPCOM leak checker will.

OK. I tried turning that on and didn't see anything, so either I was holding it wrong or I'm going to need a hint on how to add a leak to a custom build so I can write the metadata update parts for that case.

Comment 24

[Andreas Tolfsen ❲:ato❳]

Comment on attachment 8984482 [details]
Bug 1354232 - Support skipping output lines in handlers,

https://reviewboard.mozilla.org/r/250312/#review256606

Comment 25

[Andreas Tolfsen ❲:ato❳]

Comment on attachment 8984483 [details]
Bug 1354232 - Add group_metadata to test group metadata and pass it through to the browser,

https://reviewboard.mozilla.org/r/250314/#review256608

Comment 26

[Andreas Tolfsen ❲:ato❳]

Comment on attachment 8984481 [details]
Bug 1354232 - Log run-by-dir setting,

https://reviewboard.mozilla.org/r/250310/#review256612

Comment 27

[Andreas Tolfsen ❲:ato❳]

Comment on attachment 8984485 [details]
Bug 1354232 - Always try to process the leak log whenever we stop firefox,

https://reviewboard.mozilla.org/r/250318/#review256614

::: commit-message-00d0e:5
(Diff revision 1)
> +Bug 1354232 - Always try to process the leak log whenever we stop firefox, r=ato
> +
> +The `stop` method is always called to shutdown firefox, but the
> +cleanup method is only called at the end of a test run. Therefore we
> +need all the leak processing stuff ot happen in stop().

to

Comment 28

[Andrew McCreight [:mccr8]]

(In reply to James Graham [:jgraham] from comment #23)
> If a leak goes away we don't update the list because of intermittents.
> That's not ideal, but I don't know what a good solution looks like.

That's fine. People will just have to manually edit the lists, which is the same as any other harness.

> https://treeherder.mozilla.org/#/
Thanks.

> OK. I tried turning that on and didn't see anything, so either I was holding
> it wrong or I'm going to need a hint on how to add a leak to a custom build
> so I can write the metadata update parts for that case.

You can delete this line from ipc/chromium/src/chrome/common/ipc_message.cc
  MOZ_COUNT_DTOR(IPC::Message);
and it should register every IPC message as leaked.

Comment 29

[Andrew McCreight [:mccr8]]

Oh, I guess there are more leaks in the final patch besides the worker one and the DNS one.

I also see another failure or two in the logs I'm looking at that don't seem to be captured by the existing white lists. Maybe they are intermittent.

Comment 30

[Andrew McCreight [:mccr8]]

Comment on attachment 8984477 [details]
Bug 1354232 - Add support for LSAN to mozlog,

https://reviewboard.mozilla.org/r/250302/#review256714

I only looked at the lsan.py changes, but those look reasonable to me.

Comment 31

[Andrew McCreight [:mccr8]]

Comment on attachment 8984479 [details]
Bug 1354232 - Enable LSAN Leak detection in wpt,

https://reviewboard.mozilla.org/r/250306/#review256728

Comment 32

[Andrew McCreight [:mccr8]]

I just noticed this in one of the logs you linked to:
INFO | LeakSanitizer | SUMMARY: (expected) AddressSanitizer: %d byte(s) leaked in %d allocation(s).
The %d's should be numbers.

Comment 33

[Andrew McCreight [:mccr8]]

"mozilla::BackgroundHangThread::ReportHang"

Leaks like this show up in other LSan tests, so I actually have a patch up for review in bug 1467549 to disable BHR in ASan builds to "fix" this leak.

Comment 34

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

Comment on attachment 8984480 [details]
Bug 1354232 - Allow wpt manifest files to specify LSAN errors to ignore,

https://reviewboard.mozilla.org/r/250308/#review257132

Comment 35

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

Comment on attachment 8984481 [details]
Bug 1354232 - Log run-by-dir setting,

https://reviewboard.mozilla.org/r/250310/#review257150

Comment 36

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

Comment on attachment 8984484 [details]
Bug 1354232 - Add support for updating LSAN data in wpt-update

https://reviewboard.mozilla.org/r/250316/#review257152

::: commit-message-9a8af:14
(Diff revision 1)
> +
> +The rules themselves are generated by taking the topmost frame of any
> +stack that's reported as unexpectedly leaking, and adding that to the
> +list of permitted frames in the lsan-allowed property. We never remove
> +entries from this list since intermittents may be present which won't
> +appear on a specific run. Instead we rely on humand fixing the issues

humans

Comment 37

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

Comment on attachment 8984486 [details]
Bug 1354232 - Support creating ConditionalValue objects containing a list,

https://reviewboard.mozilla.org/r/250320/#review257156

Comment 38

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

Comment on attachment 8984487 [details]
Bug 1354232 - Support a __dir__.ini file in the metadata root,

https://reviewboard.mozilla.org/r/250322/#review257158

Comment 39

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

Comment on attachment 8984492 [details]
Bug 1354232 - Run web-platform-tests on linux64-asan,

https://reviewboard.mozilla.org/r/250332/#review257160

Comment 40

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

Comment on attachment 8984494 [details]
Bug 1354232 - Update metadata for lsan failures,

https://reviewboard.mozilla.org/r/250336/#review257162

Comment 41

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

Comment on attachment 8984493 [details]
Bug 1354232 - Chunk by dir more for wpt on asan,

https://reviewboard.mozilla.org/r/250334/#review257164

Comment 42

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

Comment on attachment 8984491 [details]
Bug 1354232 - Don't store the result of update_expected,

https://reviewboard.mozilla.org/r/250330/#review257166

Comment 43

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

Comment on attachment 8984488 [details]
Bug 1354232 - Fix updating assert count when there's an exising value,

https://reviewboard.mozilla.org/r/250324/#review257168

::: testing/web-platform/tests/tools/wptrunner/wptrunner/manifestupdate.py:475
(Diff revision 1)
>          if old_value is not None:
>              old_value = self.value_type(old_value)
> -        if old_value and new_value < old_value:
> +        if old_value is not None and new_value < old_value:
>              return 0
>          if old_value is None:
>              # If we are getting some asserts for the first time, set the minimum to 0

This comment is incorrect now?

Comment 44

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

Comment on attachment 8984489 [details]
Bug 1354232 - Refactor data storage in metadata.py,

https://reviewboard.mozilla.org/r/250326/#review257240

::: testing/web-platform/tests/tools/wptrunner/wptrunner/metadata.py:65
(Diff revision 1)
> -            for tree in expected_map.itervalues():
> -                for test in tree.iterchildren():
> +            for tree in expected:
> +                if not tree.modified:
> +                    continue
> +                for test in expected.iterchildren():
>                      for subtest in test.iterchildren():
>                          if subtest.new_disabled:

I'm not sure about the relationship between `tree`, `test` and `expected`. Seems like the changes result in visiting each test many times, once per modified tree, whereas previously each test was visited only once.

::: testing/web-platform/tests/tools/wptrunner/wptrunner/metadata.py:112
(Diff revision 1)
>      for item in changes:
>          rv[item[1]] = status_keys[item[0]]
>      return rv
>  
>  
>  def unexpected_changes(manifests, change_data, files_changed):

Looks like you can remove this function now.

::: testing/web-platform/tests/tools/wptrunner/wptrunner/metadata.py:331
(Diff revision 1)
>  def create_test_tree(metadata_path, test_manifest, property_order=None,
>                       boolean_properties=None):
> -    expected_map = {}
> +    """Create a map of expectation manifests for all tests in test_manifest,
> +    reading existing manifests under manifest_path
> +
> +    :returns: A map of test_id to (manifest, test, expectation_data)

Misleading comment? It seems to actually be test_id to (manifest, expectation_data)... and you get retrieve the test from expectation_data.

Comment 45

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

Comment on attachment 8984490 [details]
Bug 1354232 - Fix, enable, and add to, the manifest update tests,

https://reviewboard.mozilla.org/r/250328/#review257296

Comment 46

[Andrew Halberstadt [:ahal] (PTO Until Apr 3rd)]

Comment on attachment 8984476 [details]
Bug 1354232 - Copy LSANLeaks to mozleak,

https://reviewboard.mozilla.org/r/250300/#review257300

Comment 47

[Andrew Halberstadt [:ahal] (PTO Until Apr 3rd)]

Comment on attachment 8984477 [details]
Bug 1354232 - Add support for LSAN to mozlog,

https://reviewboard.mozilla.org/r/250302/#review257302

::: testing/mozbase/mozlog/mozlog/formatters/machformatter.py:228
(Diff revision 1)
>          return rv
>  
> +    def lsan_leak(self, data):
> +        allowed = data.get("allowed_match")
> +        if allowed:
> +            prefix = self.term.yellow("FAIL")

Should this be more obvious that the failure is allowed? Not really sure what `allowed_match` signifies.

::: testing/mozbase/mozlog/mozlog/formatters/tbplformatter.py:282
(Diff revision 1)
>  
> +    def lsan_leak(self, data):
> +        frames = data.get("frames")
> +        allowed_match = data.get("allowed_match")
> +        frame_list = ", ".join(frames)
> +        prefix = "TEST-UNEXPECTED-FAIL" if not allowed_match else "TEST-FAIL"

Ditto. Should this be TEST-KNOWN-FAIL or similar?

Comment 48

[Andrew Halberstadt [:ahal] (PTO Until Apr 3rd)]

Comment on attachment 8984478 [details]
Bug 1354232 - Ensure lsan failures cause treeherder jobs to fail,

https://reviewboard.mozilla.org/r/250304/#review257306

Comment 49

[Andrew Halberstadt [:ahal] (PTO Until Apr 3rd)]

Comment on attachment 8984479 [details]
Bug 1354232 - Enable LSAN Leak detection in wpt,

https://reviewboard.mozilla.org/r/250306/#review257308

Comment 50

[James Graham [:jgraham]]

(In reply to Andrew Halberstadt [:ahal] from comment #47)
> Comment on attachment 8984477 [details]
> Bug 1354232 - Add support for LSAN to mozlog,
> 
> https://reviewboard.mozilla.org/r/250302/#review257302
> 
> ::: testing/mozbase/mozlog/mozlog/formatters/machformatter.py:228
> (Diff revision 1)
> >          return rv
> >  
> > +    def lsan_leak(self, data):
> > +        allowed = data.get("allowed_match")
> > +        if allowed:
> > +            prefix = self.term.yellow("FAIL")
> 
> Should this be more obvious that the failure is allowed? Not really sure
> what `allowed_match` signifies.

I wasn't sure what wording to use. The content here is the topmost frame in the stack that matched a rule indicating that the leak is expected. So I'm very happy to hear alternative suggestions, but this was the best I had.

> 
> ::: testing/mozbase/mozlog/mozlog/formatters/tbplformatter.py:282
> (Diff revision 1)
> >  
> > +    def lsan_leak(self, data):
> > +        frames = data.get("frames")
> > +        allowed_match = data.get("allowed_match")
> > +        frame_list = ", ".join(frames)
> > +        prefix = "TEST-UNEXPECTED-FAIL" if not allowed_match else "TEST-FAIL"
> 
> Ditto. Should this be TEST-KNOWN-FAIL or similar?

We don't use that in other places (except in assertion checks, for some reason). So I guess it's not harmful, but it isn't what I would consider the precedent set by the existing behaviour.

Comment 51

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/05441f0a29b3
Copy LSANLeaks to mozleak, r=ahal
https://hg.mozilla.org/integration/mozilla-inbound/rev/6eda80370f59
Add support for LSAN to mozlog, r=ahal, mccr8
https://hg.mozilla.org/integration/mozilla-inbound/rev/6d28db898070
Ensure lsan failures cause treeherder jobs to fail, r=ahal
https://hg.mozilla.org/integration/mozilla-inbound/rev/e0d106c2112d
Enable LSAN Leak detection in wpt, r=ahal,mccr8
https://hg.mozilla.org/integration/mozilla-inbound/rev/b8da0ef2695d
Allow wpt manifest files to specify LSAN errors to ignore, r=maja_zf
https://hg.mozilla.org/integration/mozilla-inbound/rev/5b9ba77b7316
Log run-by-dir setting, r=maja_zf
https://hg.mozilla.org/integration/mozilla-inbound/rev/7c976baa7194
Support skipping output lines in handlers, r=ato
https://hg.mozilla.org/integration/mozilla-inbound/rev/07049ac67119
Add group_metadata to test group metadata and pass it through to the browser, r=ato
https://hg.mozilla.org/integration/mozilla-inbound/rev/9e8a66385f66
Add support for updating LSAN data in wpt-update r=maja_zf
https://hg.mozilla.org/integration/mozilla-inbound/rev/8cc292a22975
Always try to process the leak log whenever we stop firefox, r=ato
https://hg.mozilla.org/integration/mozilla-inbound/rev/c1ebcf01626a
Support creating ConditionalValue objects containing a list, r=maja_zf
https://hg.mozilla.org/integration/mozilla-inbound/rev/0e161374b583
Support a __dir__.ini file in the metadata root, r=maja_zf
https://hg.mozilla.org/integration/mozilla-inbound/rev/0f2a7154454c
Fix updating assert count when there's an exising value, r=maja_zf
https://hg.mozilla.org/integration/mozilla-inbound/rev/6bf4a20193b8
Refactor data storage in metadata.py, r=maja_zf
https://hg.mozilla.org/integration/mozilla-inbound/rev/5028820efd9e
Fix, enable, and add to, the manifest update tests, r=maja_zf
https://hg.mozilla.org/integration/mozilla-inbound/rev/004b079b76d0
Don't store the result of update_expected, r=maja_zf
https://hg.mozilla.org/integration/mozilla-inbound/rev/9d5ed234247c
Run web-platform-tests on linux64-asan, r=maja_zf
https://hg.mozilla.org/integration/mozilla-inbound/rev/a7dec081ead2
Chunk by dir more for wpt on asan, r=maja_zf
https://hg.mozilla.org/integration/mozilla-inbound/rev/7a5720fa6da9
Update metadata for lsan failures, r=maja_zf

Comment 52

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/12073 for changes under testing/web-platform/tests

Comment 53

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b9193e72be19
Annotate html/infrastructure/urls/resolving-urls/query-encoding/navigation.sub.html as passing on Linux asan. r=RyanVM on IRC

Comment 54

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/05441f0a29b3
https://hg.mozilla.org/mozilla-central/rev/6eda80370f59
https://hg.mozilla.org/mozilla-central/rev/6d28db898070
https://hg.mozilla.org/mozilla-central/rev/e0d106c2112d
https://hg.mozilla.org/mozilla-central/rev/b8da0ef2695d
https://hg.mozilla.org/mozilla-central/rev/5b9ba77b7316
https://hg.mozilla.org/mozilla-central/rev/7c976baa7194
https://hg.mozilla.org/mozilla-central/rev/07049ac67119
https://hg.mozilla.org/mozilla-central/rev/9e8a66385f66
https://hg.mozilla.org/mozilla-central/rev/8cc292a22975
https://hg.mozilla.org/mozilla-central/rev/c1ebcf01626a
https://hg.mozilla.org/mozilla-central/rev/0e161374b583
https://hg.mozilla.org/mozilla-central/rev/0f2a7154454c
https://hg.mozilla.org/mozilla-central/rev/6bf4a20193b8
https://hg.mozilla.org/mozilla-central/rev/5028820efd9e
https://hg.mozilla.org/mozilla-central/rev/004b079b76d0
https://hg.mozilla.org/mozilla-central/rev/9d5ed234247c
https://hg.mozilla.org/mozilla-central/rev/a7dec081ead2
https://hg.mozilla.org/mozilla-central/rev/7a5720fa6da9

Comment 55

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Can't merge web-platform-tests PR due to failing upstream checks:
Github PR https://github.com/web-platform-tests/wpt/pull/12073
* continuous-integration/travis-ci/pr (https://travis-ci.org/web-platform-tests/wpt/builds/405927601?utm_source=github_status&utm_medium=notification)

Comment 56

[Tiberius Oros[:tiberius_oros]]

https://hg.mozilla.org/mozilla-central/rev/b9193e72be19

Comment 57

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Can't merge web-platform-tests PR due to failing upstream checks:
Github PR https://github.com/web-platform-tests/wpt/pull/12073
* continuous-integration/travis-ci/pr (https://travis-ci.org/web-platform-tests/wpt/builds/407114828?utm_source=github_status&utm_medium=notification)

Comment 58

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged

Comment 59

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f271db900a41
[wpt PR 12073] - [Gecko Bug 1354232] Enable LSAN Leak detection in wpt, a=testonly

Comment 60

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/f271db900a41