Open Bug 1309420 Opened 3 years ago Updated 2 months ago
Intermittent e10s Leak
Sanitizer | leak at mozilla::ipc::Message Channel::On Message Received From Link, On Message Received, mozilla::ipc::Process Link::On Message Received, IPC::Channel::Channel Impl::Process Incoming Messages
59 bytes, text/x-review-board-request
Tim, I believe this leak is coming from browser/base/content/test/general/browser_tab_dragdrop2.js, I see you rewrote this test a year and a half ago- that is the only ownership of this file I can find. This is leaking quite often in linux64 ASAN e10s testing- can you help fix this or find someone to do that?
Well, this is a bug in IPC, so I don't think Tim is the best person to look at it. I can try looking into it. It looks like the failure rate went up 10x on 2016-12-29. Would it be possible to bisect what caused the regression? Failing that, I can look at what changesets landed around then. There can't be too many.
Flags: needinfo?(ttaubert) → needinfo?(jmaher)
in the past we had not been reporting leaks as orange jobs, we landed changes last week that exposed leaks and turned the jobs orange. Why we had a few of these prior to this change is the leak would show up and then another failure in the same job would occur and the job would be orange for the other failure (test failure, crash) so we would see the leak and mark it as such.
There's an X11 BadWindow error in the log before the leak error — is that normal? I'm wondering if this could be GTK exiting the process without giving us a chance to clean up. In particular, some of the leak stacks mention std::deque; it looks like we're leaking the entire MessageLoop?
I think it is actually happening in browser_tab_dragdrop.js not browser_tab_dragdrop2.js. I think Jed may be on to something. I looked at one non-failing log and I saw this: [NPAPI 1750] ###!!! ASSERTION: plug removed: 'glib assertion', file /home/worker/workspace/build/src/toolkit/xre/nsSigHandlers.cpp, line 140 instead of the Xwindow error. Though looking at the .ini file, dragdrop.js is already disabled on e10s debug (due to some timeouts), so we should probably just disable it on ASan, too, and not worry about this too much more...
I meant to link to the related bug...
See Also: → 1312436
This test seems to involve plugins, so I'll move the component over there.
Component: IPC → Plug-ins
Comment on attachment 8824253 [details] Bug 1309420 - Disable browser_tab_dragdrop for ASan leaks. https://reviewboard.mozilla.org/r/102772/#review103148
Attachment #8824253 - Flags: review?(jaws) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/ad02c08ee96f Disable browser_tab_dragdrop for ASan leaks. r=jaws
This test-only change should also get landed on Aurora.
Whiteboard: [checkin-needed Aurora]
Summary: Intermittent LeakSanitizer | leak at mozilla::ipc::MessageChannel::OnMessageReceivedFromLink, OnMessageReceived, mozilla::ipc::ProcessLink::OnMessageReceived, IPC::Channel::ChannelImpl::ProcessIncomingMessages → Intermittent e10s LeakSanitizer | leak at mozilla::ipc::MessageChannel::OnMessageReceivedFromLink, OnMessageReceived, mozilla::ipc::ProcessLink::OnMessageReceived, IPC::Channel::ChannelImpl::ProcessIncomingMessages
Whiteboard: [test disabled on ASAN] → [test disabled on ASAN][stockwell disabled]
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Component: Plug-ins → Tabbed Browser
Product: Core → Firefox
Resolution: WORKSFORME → ---
You need to log in before you can comment on or make changes to this bug.