Closed Bug 1034602 Opened 10 years ago Closed 10 years ago

Intermittent TEST-UNEXPECTED-FAIL | LeakSanitizer | leak at DeferNPObjectLastRelease, mozilla::plugins::DeferNPVariantLastRelease, mozilla::plugins::PluginScriptableObjectChild::AnswerInvoke, mozilla::plugins::PPluginScriptableObjectChild::OnCallReceived

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: mccr8, Assigned: mccr8)

References

(Blocks 1 open bug)

Details

(Keywords: intermittent-failure, memory-leak) 

Here's the stack:
Direct leak of 720 byte(s) in 18 object(s) allocated from:
#0 0x470ad1 in __interceptor_malloc /builds/slave/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:74
#1 0x7f96bae96bed in moz_xmalloc /builds/slave/m-in-l64-asan-0000000000000000/build/memory/mozalloc/mozalloc.cpp:52
#2 0x7f96bf4986b0 in operator new /builds/slave/m-in-l64-asan-0000000000000000/build/obj-firefox/dom/plugins/ipc/../../../dist/include/mozilla/mozalloc.h:201
#3 0x7f96bf4986b0 in DeferNPObjectLastRelease /builds/slave/m-in-l64-asan-0000000000000000/build/dom/plugins/ipc/PluginMessageUtils.cpp:146
#4 0x7f96bf4986b0 in mozilla::plugins::DeferNPVariantLastRelease(_NPNetscapeFuncs const*, _NPVariant*) /builds/slave/m-in-l64-asan-0000000000000000/build/dom/plugins/ipc/PluginMessageUtils.cpp:155
#5 0x7f96bf4b475e in mozilla::plugins::PluginScriptableObjectChild::AnswerInvoke(mozilla::plugins::PPluginIdentifierChild*, nsTArray<mozilla::plugins::Variant> const&, mozilla::plugins::Variant*, bool*) /builds/slave/m-in-l64-asan-0000000000000000/build/dom/plugins/ipc/PluginScriptableObjectChild.cpp:694
#6 0x7f96bd315127 in mozilla::plugins::PPluginScriptableObjectChild::OnCallReceived(IPC::Message const&, IPC::Message*&) /builds/slave/m-in-l64-asan-0000000000000000/build/obj-firefox/ipc/ipdl/./PPluginScriptableObjectChild.cpp:839
Blocks: LSan
My guess is that the call to NS_DispatchToCurrentThread in DeferNPObjectLastRelease in the child process fails, and we end up not freeing DeferNPObjectReleaseRunnable().  The fix is probably to check for failure and free the runnable if it fails.  There's no leak otherwise, so I guess it is okay to just ignore the failure otherwise.
Assignee: nobody → continuation
Depends on: 1036629
Actually this is pretty bad. I had written a comment about this here a week ago but it apparently got lost :-(

Plugin child processes don't have XPCOM at all. Therefore NS_DispatchToCurrentThread would always fail. This means that we may end up leaking large pieces of object graph until a plugin instance is unloaded, or even farther in combination with other bugs.

There are a couple things that need to happen here:

* NS_DispatchToCurrentThread should assert if XPCOM hasn't been started (if there is no thread manager). It may not be possible to do this in release builds because of perf, but it should at least be a MOZ_ASSERT in debug builds.

* This code should be using the chromium event loop (MessageLoop::current) and not XPCOM
And NS_DispatchToThread should also probably assert or runtime-abort if it ever fails: it's a programming error to dispatch an event to a dying thread, and AFAIK all other failure cases are caused by OOM.
Looks like this was indeed fixed by 1036629.  I filed bug 1038955 for comment 8 and 9.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.