Implementation of PostTaskAndReply() in MessageLoopProxy and BrowserThread.

tools/valgrind/memcheck/suppressions.txt

Index: tools/valgrind/memcheck/suppressions.txt
diff --git a/tools/valgrind/memcheck/suppressions.txt b/tools/valgrind/memcheck/suppressions.txt
index 17f258bb2552aa9e83c1df8cd0b9ea88fdd86a04..ee5c880c301929bb7533f02bd7f9cfbdc4fc10aa 100644
--- a/tools/valgrind/memcheck/suppressions.txt
+++ b/tools/valgrind/memcheck/suppressions.txt
@@ -745,6 +745,13 @@
    fun:_ZN4base40ToolsSanityTest_AccessesToNewMemory_Test8TestBodyEv
 }
 {
+   This test explicitly verifies PostTaskAndReply leaks the task if the originating MessageLoop has been deleted.

[Nico, 2011/08/18 18:05:28]

No bug #?

[awong, 2011/08/18 18:18:56]

I'm not sure it is a bug...

[Nico, 2011/08/18 18:32:34]

I meant more "See http://crbug.com/86301" to save someone curious the `git
blame` call in the future. This doesn't need a tracking bug, I agree. Just for
reference.

+   Memcheck:Leak
+   fun:_Znw*
+   fun:_ZN4base16MessageLoopProxy16PostTaskAndReplyERKN15tracked_objects8LocationERKNS_8CallbackIFvvEEES9_
+   fun:_ZN4base12_GLOBAL__N_169MessageLoopProxyTest_PostTaskAndReply_DeadReplyLoopDoesNotDelete_Test8TestBodyEv

[Nico, 2011/08/18 18:05:28]

GLOBAL might mangle differently on OS X, don't remember

[awong, 2011/08/18 18:18:56]

Okay I don't have a mac handy. Will watch the waterfall.

+}
+{
    logging::InitLogging never frees filename. It would be hard to free properly.
    Memcheck:Leak
    ...