mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-24 05:11:16 +00:00
Bug 1089816 - Let ASan content processes run to completion. r=billm
There are a variety of ways that the parent and child process ensure that the child process exits quickly in opt builds, but for AddressSanitizer builds we want to let the child process to run to completion, so that we can get a LeakSanitizer report. This requires adding some addition LSan suppressions, because running LSan in child processes detects some new leaks.
This commit is contained in:
parent
a5dd663397
commit
ef6d1e9493
@ -41,6 +41,13 @@ leak:nr_reg_set
|
||||
# Additional WebRTC leak suppressions added for Mochitest 3.
|
||||
leak:mozilla::TransportLayerDtls::Setup
|
||||
|
||||
# Bug 1187424 - DesktopApplication does not free any of its string members.
|
||||
leak:webrtc::DesktopApplication::
|
||||
|
||||
# Bug 1187518 - SCTP leaks in child process while running WebRTC tests.
|
||||
leak:recv_function_udp
|
||||
|
||||
|
||||
###
|
||||
### Many leaks only affect some test suites. The suite annotations are not checked.
|
||||
###
|
||||
@ -85,6 +92,22 @@ leak:_PR_Getfd
|
||||
# Bug 1028483 - The XML parser sometimes leaks an object. bc3
|
||||
leak:processInternalEntity
|
||||
|
||||
# Bug 1187421 - With e10s, NSS does not always free the error stack. m1.
|
||||
leak:nss_ClearErrorStack
|
||||
|
||||
# Bug 1090570 - IPC Transport lifetime is not always managed correctly.
|
||||
leak:mozilla::ipc::OpenDescriptor
|
||||
leak:IPC::Channel::ChannelImpl::OutputQueuePush
|
||||
leak:IPC::Channel::Channel
|
||||
leak:base::MessagePumpLibevent::WatchFileDescriptor
|
||||
|
||||
# Bug 1122045 - Leaks in MessageLoop::MessageLoop()
|
||||
leak:MessageLoop::MessageLoop
|
||||
# This may not actually be related to MessageLoop.
|
||||
leak:base::WaitableEvent::TimedWait
|
||||
leak:MessageLoop::PostTask_Helper
|
||||
|
||||
|
||||
###
|
||||
### Leaks with system libraries in their stacks. These show up across a number of tests.
|
||||
### Better symbols and disabling fast stackwalking may help diagnose these.
|
||||
|
@ -1909,7 +1909,7 @@ ContentChild::ActorDestroy(ActorDestroyReason why)
|
||||
QuickExit();
|
||||
}
|
||||
|
||||
#ifndef DEBUG
|
||||
#if !defined(DEBUG) and !defined(MOZ_ASAN)
|
||||
// In release builds, there's no point in the content process
|
||||
// going through the full XPCOM shutdown path, because it doesn't
|
||||
// keep persistent state.
|
||||
|
@ -125,7 +125,8 @@ GeckoChildProcessHost::~GeckoChildProcessHost()
|
||||
SharedMemoryBasic::CleanupForPid(mChildProcessHandle);
|
||||
#endif
|
||||
ProcessWatcher::EnsureProcessTerminated(mChildProcessHandle
|
||||
#if defined(NS_BUILD_REFCNT_LOGGING)
|
||||
#if defined(NS_BUILD_REFCNT_LOGGING) || defined(MOZ_ASAN)
|
||||
// If we're doing leak logging, shutdown can be slow.
|
||||
, false // don't "force"
|
||||
#endif
|
||||
);
|
||||
|
@ -2461,7 +2461,7 @@ pref("plugin.sessionPermissionNow.intervalInMinutes", 60);
|
||||
// to allow it persistently.
|
||||
pref("plugin.persistentPermissionAlways.intervalInDays", 90);
|
||||
|
||||
#ifndef DEBUG
|
||||
#if !defined(DEBUG) && !defined(MOZ_ASAN)
|
||||
// How long a plugin is allowed to process a synchronous IPC message
|
||||
// before we consider it "hung".
|
||||
pref("dom.ipc.plugins.timeoutSecs", 45);
|
||||
@ -2487,7 +2487,7 @@ pref("dom.ipc.plugins.hangUIMinDisplaySecs", 10);
|
||||
// we fear the worst and kill it.
|
||||
pref("dom.ipc.tabs.shutdownTimeoutSecs", 5);
|
||||
#else
|
||||
// No timeout in DEBUG builds
|
||||
// No timeout in DEBUG or ASan builds
|
||||
pref("dom.ipc.plugins.timeoutSecs", 0);
|
||||
pref("dom.ipc.plugins.contentTimeoutSecs", 0);
|
||||
pref("dom.ipc.plugins.processLaunchTimeoutSecs", 0);
|
||||
|
Loading…
Reference in New Issue
Block a user