Closed Bug 1207431 Opened 9 years ago Closed 8 years ago

Intermittent leakcheck | default process: 600 bytes leaked (CondVar, Mutex, nsRunnable, nsTArray_base, nsThread, ...)

Categories

(Core :: WebRTC: Audio/Video, defect, P1)

Product:
Core
Component:
WebRTC: Audio/Video
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla49
Tracking Flags:
Tracking Status
firefox47 --- fixed
firefox48 --- fixed
firefox49 --- fixed
Blocking Flags:
backlog webrtc/webaudio+

People

(Reporter: nigelb, Assigned: jesup)

References

Details

(Keywords: intermittent-failure, memory-leak) 

      No description provided.
This is currently the #2 leak on OrangeFactor.

Leak stack:
 11:22:53     INFO -  #00: mozilla::CondVar::CondVar(mozilla::Mutex&, char const*) [xpcom/glue/CondVar.h:47]
 11:22:53     INFO -  #01: nsThread::nsThread(nsThread::MainThreadFlag, unsigned int) [xpcom/glue/nsTArray.h:834]
 11:22:53     INFO -  #02: nsThreadManager::NewThread(unsigned int, unsigned int, nsIThread**) [xpcom/threads/nsThreadManager.cpp:252]
 11:22:53     INFO -  #03: NS_NewThread(nsIThread**, nsIRunnable*, unsigned int) [xpcom/glue/nsThreadUtils.cpp:72]
 11:22:53     INFO -  #04: mozilla::camera::GetCamerasChild() [xpcom/glue/nsThreadUtils.h:76]
 11:22:53     INFO -  #05: mozilla::MediaEngineWebRTC::EnumerateVideoDevices(mozilla::dom::MediaSourceEnum, nsTArray<RefPtr<mozilla::MediaEngineVideoSource> >*) [dom/media/systemservices/CamerasChild.h:133]
 11:22:53     INFO -  #06: mozilla::media::LambdaTask<mozilla::MediaManager::EnumerateRawDevices(uint64_t, mozilla::dom::MediaSourceEnum, mozilla::dom::MediaSourceEnum, bool, bool)::<lambda()> >::Run [dom/media/MediaManager.cpp:1053]
 11:22:53     INFO -  #07: MessageLoop::RunTask(Task*) [ipc/chromium/src/base/message_loop.cc:365]
 11:22:53     INFO -  #08: MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) [ipc/chromium/src/base/message_loop.cc:375]
 11:22:53     INFO -  #09: MessageLoop::DoWork() [ipc/chromium/src/base/message_loop.cc:459]
 11:22:53     INFO -  #10: mozilla::ipc::DoWorkRunnable::Run() [ipc/glue/MessagePump.cpp:221]
 11:22:53     INFO -  #11: nsThread::ProcessNextEvent(bool, bool*) [xpcom/threads/nsThread.cpp:1018]
 11:22:53     INFO -  #12: NS_ProcessNextEvent(nsIThread*, bool) [xpcom/glue/nsThreadUtils.cpp:297]
 11:22:53     INFO -  #13: mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) [ipc/glue/MessagePump.cpp:355]
 11:22:53     INFO -  #14: MessageLoop::RunInternal() [ipc/chromium/src/base/message_loop.cc:235]
 11:22:53     INFO -  #15: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:520]
 11:22:53     INFO -  #16: base::Thread::ThreadMain() [ipc/chromium/src/base/thread.cc:175]
 11:22:53     INFO -  #17: ThreadFunc [ipc/chromium/src/base/platform_thread_posix.cc:38]
 11:22:53     INFO -  #18: libpthread.so.0 + 0x7e9a
11:22:53 INFO - #19: libc.so.6 + 0xf338d
Component: General → WebRTC: Audio/Video
Keywords: mlk
Product: Firefox → Core
See Also: → 1251123
Did this start spiking after bug 1249313?
Flags: needinfo?(ryanvm)
backlog: --- → webrtc/webaudio+
Rank: 10
Priority: -- → P1
I'm ok with backing out bug 1249313 to get this orange under control. I think there's no functional impact with the current MediaManager workings.

The patch in that bug is likely correct, but if it's causing so much sherrifing pain I think we can pull it till we figure out why it's making the orange worse.
Flags: needinfo?(ryanvm)
Flags: needinfo?(ryanvm)
(In reply to Gian-Carlo Pascutto [:gcp] from comment #14)
> I'm ok with backing out bug 1249313 to get this orange under control. I
> think there's no functional impact with the current MediaManager workings.
> 
> The patch in that bug is likely correct, but if it's causing so much
> sherrifing pain I think we can pull it till we figure out why it's making
> the orange worse.

I think we should back out, especially given "no functional impact".  Also, is bug 1251123 a dup of this?  If so, let's mark it as such.
Assignee: nobody → gpascutto
Flags: needinfo?(gpascutto)
It was already backed out.
Flags: needinfo?(gpascutto)
Bug 1252647 may or may not be a dupe too.
FWIW I've been trying to track this down to no avail so far, because it was happening almost permanently with bug 1250990 (before the backout of course, trying again now to see if it has improved).

As I understand it, the Camera IPC thread gets runnables both from the IPC thread and the MediaManager thread.

Seems there's occasionally (almost permanently with bug 1250990) an outstanding runnable at time of termination. I think we'd need to instrument more to see where it is coming from. There's certainly a lot of code to ensure this doesn't happen, so it's hard to tell what it could be.
(In reply to Jan-Ivar Bruaroey [:jib] from comment #20)
> Seems there's occasionally (almost permanently with bug 1250990) an
> outstanding runnable at time of termination. I think we'd need to instrument
> more to see where it is coming from. There's certainly a lot of code to
> ensure this doesn't happen, so it's hard to tell what it could be.

Bug 1252647 seems to point to the ThreadDestructor being a possibility, although who knows there might be two leaks :-/
Looking good so far since bug 1267600 landed.
Depends on: 1267600
No OrangeFactor hits for this since bug 1267600 landed. Calling this fixed!
Assignee: gpascutto → rjesup
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox44: affected → ---
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox49: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Target Milestone: mozilla48 → mozilla49
You need to log in before you can comment on or make changes to this bug.