Open Bug 1309420 Opened 3 years ago Updated 2 months ago

Intermittent e10s LeakSanitizer | leak at mozilla::ipc::MessageChannel::OnMessageReceivedFromLink, OnMessageReceived, mozilla::ipc::ProcessLink::OnMessageReceived, IPC::Channel::ChannelImpl::ProcessIncomingMessages

Categories

(Firefox :: Tabbed Browser, defect, P3)

defect

Tracking

()

REOPENED
Tracking Status
firefox51 --- disabled
firefox52 --- disabled
firefox53 --- disabled

People

(Reporter: intermittent-bug-filer, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: intermittent-failure, leave-open, memory-leak, Whiteboard: [test disabled on ASAN][stockwell disabled])

Attachments

(1 file)

Blocks: LSan
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?
Flags: needinfo?(ttaubert)
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.
Flags: needinfo?(jmaher)
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 amccreight@mozilla.com:
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.
Keywords: checkin-needed
Whiteboard: [checkin-needed Aurora]
Whiteboard: [checkin-needed Aurora] → [test disabled on ASAN][checkin-needed-aurora][checkin-needed-beta]
See Also: → 1239258
Depends on: 1237853
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
Depends on: 1331320
Whiteboard: [test disabled on ASAN] → [test disabled on ASAN][stockwell disabled]
Priority: -- → P3
Keywords: mlk
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → WORKSFORME

Oops, I failed to notice that this test was just disabled... That explains why it was still open! Sorry for the noise.

Status: RESOLVED → REOPENED
Component: Plug-ins → Tabbed Browser
Keywords: leave-open
Product: Core → Firefox
Resolution: WORKSFORME → ---
You need to log in before you can comment on or make changes to this bug.