Closed
Bug 1101264
Opened 6 years ago
Closed 6 years ago
crash in OOM | large | NS_ABORT_OOM(unsigned int) | Pickle::Pickle(Pickle const&)
Categories
(Core :: IPC, defect)
Tracking
()
RESOLVED
FIXED
mozilla44
Tracking | Status | |
---|---|---|
firefox44 | --- | fixed |
People
(Reporter: guigs, Assigned: dmajor)
References
Details
(Keywords: crash, Whiteboard: [MemShrink:P2])
Crash Data
Attachments
(1 file)
1.17 KB,
patch
|
bent.mozilla
:
review+
|
Details | Diff | Splinter Review |
This bug was filed from the Socorro interface and is report bp-8bf164a9-5658-496e-923d-1c54d2141118. ============================================================= stacktrace: Frame Module Signature Source 0 xul.dll NS_ABORT_OOM(unsigned int) xpcom/base/nsDebugImpl.cpp 1 xul.dll Pickle::Pickle(Pickle const&) ipc/chromium/src/base/pickle.cc 2 xul.dll IPC::Message::Message(IPC::Message const&) ipc/chromium/src/chrome/common/ipc_message.cc 3 xul.dll std::_Cons_val<std::allocator<IPC::Message>, IPC::Message, IPC::Message const&>(std::allocator<IPC::Message>&, IPC::Message*, IPC::Message const&) c:/program files (x86)/microsoft visual studio 10.0/vc/include/xmemory:280 4 xul.dll std::deque<IPC::Message, std::allocator<IPC::Message> >::push_back(IPC::Message const&) c:/program files (x86)/microsoft visual studio 10.0/vc/include/deque:1267 5 xul.dll mozilla::ipc::MessageChannel::OnMessageReceivedFromLink(IPC::Message const&) ipc/glue/MessageChannel.cpp 6 xul.dll mozilla::ipc::ProcessLink::OnMessageReceived(IPC::Message const&) ipc/glue/MessageLink.cpp 7 xul.dll IPC::Channel::ChannelImpl::ProcessIncomingMessages(base::MessagePumpForIO::IOContext*, unsigned long) ipc/chromium/src/chrome/common/ipc_channel_win.cc 8 xul.dll IPC::Channel::ChannelImpl::OnIOCompleted(base::MessagePumpForIO::IOContext*, unsigned long, unsigned long) ipc/chromium/src/chrome/common/ipc_channel_win.cc 9 xul.dll base::MessagePumpForIO::WaitForIOCompletion(unsigned long, base::MessagePumpForIO::IOHandler*) ipc/chromium/src/base/message_pump_win.cc 10 xul.dll base::MessagePumpForIO::DoRunLoop() ipc/chromium/src/base/message_pump_win.cc 11 xul.dll base::MessagePumpWin::RunWithDispatcher(base::MessagePump::Delegate*, base::MessagePumpWin::Dispatcher*) ipc/chromium/src/base/message_pump_win.cc 12 xul.dll base::MessagePumpWin::Run(base::MessagePump::Delegate*) ipc/chromium/src/base/message_pump_win.h 13 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 14 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 15 xul.dll base::Thread::ThreadMain() ipc/chromium/src/base/thread.cc 16 xul.dll `anonymous namespace'::ThreadFunc(void*) ipc/chromium/src/base/platform_thread_win.cc 17 kernel32.dll BaseThreadInitThunk 18 ntdll.dll __RtlUserThreadStart 19 ntdll.dll _RtlUserThreadStart Adapter Description: NVIDIA GeForce GTX 680 Adapter Drivers: nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Adapter RAM: 2048 Device ID: 0x1180 DirectWrite Enabled: false (6.2.9200.16492) Driver Date: 11-3-2014 Driver Version: 9.18.13.4465 GPU #2 Active: false GPU Accelerated Windows: 0/1 Basic (OMTC) Vendor ID: 0x10de WebGL Renderer: Google Inc. -- ANGLE (NVIDIA GeForce GTX 680 Direct3D9Ex vs_3_0 ps_3_0) windowLayerManagerRemote: true AzureCanvasBackend: skia AzureContentBackend: cairo AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0
Updated•6 years ago
|
Component: General → IPC
Product: Firefox → Core
Updated•6 years ago
|
Whiteboard: [MemShrink]
Comment 1•6 years ago
|
||
There's some discussion about this in bug 1092010. Two theories that have been presented for why we are seeing these OOM crashes in non-e10s browsers is the compositor thread or the thumbnail thread may be sending large messages.
The larger problem is that this user's Firefox pretty consistently consumes >3gb of memory within the first 30 seconds of startup. These IPC messages may just be the first victims due to their size.
Long story short it was adware/malware. When opening about:newtab, an instance of plugin-container shows up, allocates several gigs of memory within a second, and disappears. But the Pickles stay allocated on the FF side. Anybody want me to pull any more information before I pave the infected machine?
Well I did find some interesting things nonetheless. Going to about:newtab causes an instance of plugin-container to appear (not exactly sure why, I vaguely recall the stacks saying RemoteBrowser or some such). That plugin-container encounters a bunch of CSS errors. It's basically the same problem as bug 976777 except the troublesome variable is not |sourceLine| but rather |sourceName| which is a massive data: url from an addon. The other thing is that these IPC messages accumulate on the firefox.exe side, but I don't see them ever get deallocated. Haven't yet debugged this super closely.
Comment 6•6 years ago
|
||
That plugin-container is a content process charged with generating thumbnails for about:newtab (this is in all builds, not just e10s builds). Does that mean this is solved with bug 976777 or is there still work to be done?
Flags: needinfo?(dmajor)
There is still (easy) work to be done. Bug 976777 fixed the problem with |sourceLine|; we just need to do the same with |sourceName|.
Assignee: nobody → dmajor
Flags: needinfo?(dmajor)
Well, we should also try to harden the parent process against this by not explicitly aborting... I would much rather it trigger the death of the child process.
This seems like a straightforward fix that we can just go ahead and make. bent, if you have ideas for attacking the issue from another angle, then I totally support that too, either as a leave-open or a spinoff bug or what have you.
Attachment #8534084 -
Flags: review?(bent.mozilla)
Attachment #8534084 -
Flags: review?(bent.mozilla) → review+
![]() |
Assignee | |
Comment 10•6 years ago
|
||
Oh no! This fell off my radar and I never landed it. It's unclear whether that adware is still going around, but it seems like we're still susceptible to badness here, so I'll push...
Comment 12•6 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/4c0e0c5176e9
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox44:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
You need to log in
before you can comment on or make changes to this bug.
Description
•