Closed Bug 1439973 Opened 7 years ago Closed 7 years ago

NSPR assertion failure on OSX with run-by-manifest in layout/reftests/webcomponents/reftest.list

Categories

(Core :: DOM: Core & HTML, defect)

x86_64
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1399746

People

(Reporter: ahal, Unassigned)

References

Details

In bug 1353461 we are in the process of switching reftest to "run-by-manifest" mode. This means that between every manifest of tests we will restart Firefox. In general this leads to improved stability, though in a few cases existing tests that happened to depend on side-effects of previous tests can start failing. This is one of those cases. In this instance, there is a perma memory leak after running the tests in layout/reftests/webcomponents/reftest.list. Here is a push showing this: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e53ddd2a3870117db53f466219fcfed9ffade9bd Example log: https://treeherder.mozilla.org/logviewer.html#?job_id=163442959&repo=try&lineNumber=38234 We'll need to fix this before landing run-by-manifest, or else we'll need to skip the entire manifest on OSX debug.
Emilio, is this something you might be able to help with?
Flags: needinfo?(emilio)
That doesn't look like a memory leak at all, it's an assertion in nspr: Assertion failure: 0 == rv, at /builds/worker/workspace/build/src/nsprpub/pr/src/pthreads/ptthread.c:277 Looks somewhat related to bug 1399746. Glandium, any idea?
Flags: needinfo?(emilio) → needinfo?(mh+mozilla)
Thanks, my mistake. Feel free to dupe if it's the same.
Summary: Leaking the world on OSX with run-by-manifest in layout/reftests/webcomponents/reftest.list → NSPR assertion failure on OSX with run-by-manifest in layout/reftests/webcomponents/reftest.list
This is somewhat good news, because it means we can actually finally reproduce this more reliably, with a Firefox build.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(mh+mozilla)
Resolution: --- → DUPLICATE
Actually, it *is* a leak. The nspr assert comes *afterwards*, during shutdown. It does help with reproducing that nspr assert, though, since it's so reliably happening.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Flags: needinfo?(emilio)
I'm stunned, the leak message actually goes away when bug 1399746 is fixed.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Flags: needinfo?(emilio)
Resolution: --- → DUPLICATE
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.