diff options
| author | hbono@chromium.org <hbono@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-12-10 06:08:33 +0000 |
|---|---|---|
| committer | hbono@chromium.org <hbono@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-12-10 06:08:33 +0000 |
| commit | 68cb86a3a8190776fc0b8bc34cc0e5124edfdd03 (patch) | |
| tree | 1ebe72a84b06dbc8bd40b3dbf9075409d70b6954 | |
| parent | df3b98079330f47762f3a62d0402b284ba0fceea (diff) | |
| download | chromium_src-68cb86a3a8190776fc0b8bc34cc0e5124edfdd03.zip chromium_src-68cb86a3a8190776fc0b8bc34cc0e5124edfdd03.tar.gz chromium_src-68cb86a3a8190776fc0b8bc34cc0e5124edfdd03.tar.bz2 | |
An exprimental fix for Bug 65940.
It seems these leaks are caused by a reference-count mismatch for a ChannelProxy::Context object. (This class expects to increase its reference count in OnChannelOpened() and to decrease it in OnChannelClosed(). On the other hand, we cannot call OnChannelClosed() after calling ClearIPCMessageLoop() because it detaches the message loop of a ChannelProxy::Context object. That is, calling ChannelProxy::Close() in ChannelProxy::~ChannelProxy() cannot decrease the reference count to its context.) This change just explicitly calls ChannelProxy::Close() before calling ChannelProxy::ClearIPCMessageLoop().
BUG=65940
TEST=make the valgrind bot green without suppressions.
Review URL: http://codereview.chromium.org/5706001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68831 0039d316-1c4b-4281-b951-d872f2087c98
| -rw-r--r-- | chrome/common/child_thread.cc | 5 | ||||
| -rw-r--r-- | tools/valgrind/memcheck/suppressions.txt | 19 |
2 files changed, 5 insertions, 19 deletions
diff --git a/chrome/common/child_thread.cc b/chrome/common/child_thread.cc index b59a559..848f1e18 100644 --- a/chrome/common/child_thread.cc +++ b/chrome/common/child_thread.cc @@ -71,6 +71,11 @@ ChildThread::~ChildThread() { channel_->RemoveFilter(sync_message_filter_.get()); + // Close this channel before resetting the message loop attached to it so + // the message loop can call ChannelProxy::Context::OnChannelClosed(), which + // releases the reference count to this channel. + channel_->Close(); + // The ChannelProxy object caches a pointer to the IPC thread, so need to // reset it as it's not guaranteed to outlive this object. // NOTE: this also has the side-effect of not closing the main IPC channel to diff --git a/tools/valgrind/memcheck/suppressions.txt b/tools/valgrind/memcheck/suppressions.txt index b84c780..90c7c6d 100644 --- a/tools/valgrind/memcheck/suppressions.txt +++ b/tools/valgrind/memcheck/suppressions.txt @@ -3461,25 +3461,6 @@ fun:_ZN7WebCore11RenderBlock37computeBlockDirectionPositionsForLineEPNS_13RootInlineBoxEPNS_7BidiRunERN3WTF7HashMapIPKNS_13InlineTextBoxESt4pairINS5_6VectorIPKNS_14SimpleFontDataELj0EEENS_13GlyphOverflowEENS5_7PtrHashIS9_EENS5_10HashTraitsIS9_EENSK_ISH_EEEERNS_21VerticalPositionCacheE } { - bug_65940_a - Memcheck:Leak - fun:_Znw* - ... - fun:_ZN3IPC12ChannelProxy7Context13CreateChannelERKNS_13ChannelHandleERKNS_7Channel4ModeE - fun:_ZN3IPC12ChannelProxy4InitERKNS_13ChannelHandleENS_7Channel4ModeEP11MessageLoopb - fun:_ZN3IPC12ChannelProxyC2ERKNS_13ChannelHandleENS_7Channel4ModeEP11MessageLoopPNS0_7ContextEb - fun:_ZN3IPC11SyncChannelC1ERKNS_13ChannelHandleENS_7Channel4ModeEPNS4_8ListenerEP11MessageLoopbPN4base13WaitableEventE -} -{ - bug_65940_b - Memcheck:Leak - fun:_Znw* - fun:_ZN3IPC11SyncChannelC1ERKNS_13ChannelHandleENS_7Channel4ModeEPNS4_8ListenerEP11MessageLoopbPN4base13WaitableEventE - fun:_ZN11ChildThread4InitEv - fun:_ZN11ChildThreadC2ERKSs - fun:_ZN12RenderThreadC1ERKSs -} -{ bug_65988 Memcheck:Leak fun:_Znw* |