Closed Bug 1300017 Opened 8 years ago Closed 7 years ago

Intermittent leakcheck | plugin process: 860 bytes leaked (CancelableRunnable, CondVar, IPC::Channel, Mutex, PPluginModuleChild, ...)

Categories

(Core Graveyard :: Plug-ins, defect, P5)

defect

Tracking

(firefox52 fixed, firefox-esr52 fixed, firefox53 fixed, firefox54 fixed)

RESOLVED FIXED
mozilla54
Tracking Status
firefox52 --- fixed
firefox-esr52 --- fixed
firefox53 --- fixed
firefox54 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: gbrown)

References

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell disabled])

Attachments

(1 file)

Priority: -- → P5
Trying to reproduce this, I also see bug 1332034 sometimes.
See Also: → 1332034
At least on Beta, this failure appears to happen in tandem with bug 1315855.
:gbrown, we are into the 4th week of this being medium/high frequency- do you think there is more work here, or should we find the specific test and disable?
Flags: needinfo?(gbrown)
We should follow-up on comment 7, or try disabling that test, crashtests/295292-1.html. All recent failures in bug 1315855 are assertion count mismatches on beta and have a similar leak. The assertion count mismatch is not seen on trunk, perhaps only because the test was annotated.
See Also: → 1315855
Whiteboard: [stockwell needswork]
(In reply to Geoff Brown [:gbrown] from comment #11)
> We should follow-up on comment 7, or try disabling that test,
> crashtests/295292-1.html. All recent failures in bug 1315855 are assertion
> count mismatches on beta and have a similar leak. The assertion count
> mismatch is not seen on trunk, perhaps only because the test was annotated.

But according to https://bugzilla.mozilla.org/show_bug.cgi?id=1315855#c12, bug 1315855 is fixed by bug 1338172, on trunk; this bug's leak continues, so I guess it is a separate issue.

We'll need to find the specific test and disable.
Flags: needinfo?(gbrown)
(In reply to Geoff Brown [:gbrown] from comment #13)
> We'll need to find the specific test and disable.

If you look at the bloat view that includes the leaks, it will show you what the pid is for the leaking process:
== BloatView: ALL (cumulative) LEAK AND BLOAT STATISTICS, plugin process 1433
Then, you can search the log for [NPAPI 1433] (because this is a plugin process) and then search backwards from there for TEST-START to see which test is running when we start the plugin process. I think for plugin processes we'll always start a new one during the leaking test.

Looking at a couple of recent logs, this is happening in reftest/tests/widget/cocoa/crashtests/373122-1.html

Why we're running a Cocoa widget test on Linux I do not know...
Genius! Thanks!
Assignee: nobody → gbrown
No sign of leaks in the try run. 

As noted, it doesn't seem to make sense to run these cocoa crashtests on non-cocoa platforms anyway.
Attachment #8841792 - Flags: review?(jmaher)
Comment on attachment 8841792 [details] [diff] [review]
skip leaking cocoa crashtest on !cocoa

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

thanks
Attachment #8841792 - Flags: review?(jmaher) → review+
Whiteboard: [stockwell needswork] → [stockwell disabled]
Pushed by gbrown@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/02fb91584ef6
Skip crashtest 373122-1.html except on osx, for intermittent leaks; r=jmaher
https://hg.mozilla.org/mozilla-central/rev/02fb91584ef6
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: