Issue 50003  has been merged into this issue.

My change was in the Windows sandbox code. So, I think I'm safe from blame on this one.

(adding a few more people who modified the lines shown on the stack)

Chase, brettw

May I ask you a favor? Can one of you look into this and find out what's causing this leak?

I'm not familiar with these code enough to identify one.

Thanks.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=53478 

------------------------------------------------------------------------
r53478 | oshima@chromium.org | 2010-07-23 09:23:06 -0700 (Fri, 23 Jul 2010) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/tools/valgrind/memcheck/suppressions_mac.txt?r1=53478&r2=53477

suppression for Memcheck:Cond in ResourceDispatcherHostTest_TestMany

TBR=chase@chromium.org
BUG=50002
TEST=valgrind unit test on mac should cycle green

Review URL: http://codereview.chromium.org/3048018
------------------------------------------------------------------------

(No comment was entered for this change.)

Regression so M6/p1.

(No comment was entered for this change.)

This is now crashing. I'll exclude the test.


[ RUN      ] ResourceDispatcherHostTest.TestMany
[57726:1291:0723/125024:4935031018440742:FATAL:/b/slave/chromium-dbg-mac-valgrind/build/src/base/pickle.cc(95)] Check failed: 0 == tmp || 1 == tmp.
Backtrace:
	0   unit_tests                          0x0174d049 start + 24420089
	1   unit_tests                          0x0175ac99 start + 24476489
	2   unit_tests                          0x01763701 start + 24511921
	3   unit_tests                          0x01228ba1 start + 19028561
	4   unit_tests                          0x01228c59 start + 19028745
	5   unit_tests                          0x0077e87e start + 7845678
	6   unit_tests                          0x010b6e90 start + 17513792
	7   unit_tests                          0x010b2b07 start + 17496503
	8   unit_tests                          0x004680b3 start + 4607843
	9   unit_tests                          0x0046c12b start + 4624347
	10  unit_tests                          0x0139b10b start + 20545467
	11  unit_tests                          0x0139b1c0 start + 20545648
	12  unit_tests                          0x0139b298 start + 20545864
	13  unit_tests                          0x0139d7c3 start + 20555379
	14  unit_tests                          0x012e699e start + 19806286
	15  unit_tests                          0x012e59dd start + 19802253
	16  unit_tests                          0x00003186 start + 54

[57726:1291:0723/125024:4935031018440742:FATAL:/b/slave/chromium-dbg-mac-valgrind/build/src/base/pickle.cc(95)] Check failed: 0 == tmp || 1 == tmp.
Backtrace:
	0   unit_tests                          0x0174d049 start + 24420089
	1   unit_tests                          0x0175ac99 start + 24476489
	2   unit_tests                          0x01763701 start + 24511921
	3   unit_tests                          0x01228ba1 start + 19028561
	4   unit_tests                          0x01228c59 start + 19028745
	5   unit_tests                          0x0077e87e start + 7845678
	6   unit_tests                          0x010b6e90 start + 17513792
	7   unit_tests                          0x010b2b07 start + 17496503
	8   unit_tests                          0x004680b3 start + 4607843
	9   unit_tests                          0x0046c12b start + 4624347
	10  unit_tests                          0x0139b10b start + 20545467
	11  unit_tests                          0x0139b1c0 start + 20545648
	12  unit_tests                          0x0139b298 start + 20545864
	13  unit_tests                          0x0139d7c3 start + 20555379
	14  unit_tests                          0x012e699e start + 19806286
	15  unit_tests                          0x012e59dd start + 19802253
	16  unit_tests                          0x00003186 start + 54

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=53507 

------------------------------------------------------------------------
r53507 | oshima@chromium.org | 2010-07-23 13:34:38 -0700 (Fri, 23 Jul 2010) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/valgrind/unit_tests.gtest_mac.txt?r1=53507&r2=53506
   M http://src.chromium.org/viewvc/chrome/trunk/src/tools/valgrind/memcheck/suppressions_mac.txt?r1=53507&r2=53506

Exclude ResourceDispatcherHost_TestMany from valgrind test

TBR=chase@chromium.org
BUG=50002
TEST=mac valigrind unit test should cycle green.

Review URL: http://codereview.chromium.org/2806072
------------------------------------------------------------------------

This could be http://codereview.chromium.org/3053009

Darin, 

You added boolean to ViewHostMsg_Resource_Request, and this test is failing in Picle::ReadBool.
Could you please take a look and check if new field is correctly unmarhalled?

thanks

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=53555 

------------------------------------------------------------------------
r53555 | oshima@chromium.org | 2010-07-23 17:16:41 -0700 (Fri, 23 Jul 2010) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/valgrind/unit_tests.gtest_mac.txt?r1=53555&r2=53554

Exclude ResourceDispatcherHost.Cancel
 This is same cause as 50002.

TBR=darin@chromium.org
BUG=50002
TEST=none

Review URL: http://codereview.chromium.org/3046019
------------------------------------------------------------------------

From what I can tell there's more going on here that made this harder to pinpoint.

r53378 (Darin's change to render_messages.h) landed at 1:52pm on Thursday and was picked up in build 6672, yet the stack trace in comment 0 doesn't appear in a valgrind error until build 6676 (when this bug was filed).

Going further back:
- build 6667 is ok
- builds 6668 to 6674 has a webkit_glue::FormData error
- build 6675 has a different webkit_glue::FormData error
- build 6676 has the stack trace in comment 0

Since this builder doesn't clobber, it looks like Darin's change didn't actually trigger a recompile for valgrind to catch the new error (which went undetected for 4 builds).  Perhaps jhawkins's AutoFill change triggered enough of a rebuild to catch Darin's change and surface the error.  Oshima, wdyt?

Note there might be one or two other errors lurking once Darin's is cleared up.  See builds 6668-6675.

I investigate further and found why we started seeing this a lot later than Darin submitted the change.

When Darin submitted the change, there was another (and similar) error which was causing crash and ResourceDispatchHostTest was never run in this cycle. jhawkins fixed this in r53385, the test run further and hit this bug. 

Lei, we need to fix this because valgrind takes longer and missing tests run when one test is crashing makes it difficult to troubleshoot.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=53568 

------------------------------------------------------------------------
r53568 | oshima@chromium.org | 2010-07-23 19:38:26 -0700 (Fri, 23 Jul 2010) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/valgrind/unit_tests.gtest_mac.txt?r1=53568&r2=53567
   M http://src.chromium.org/viewvc/chrome/trunk/src/tools/valgrind/memcheck/suppressions.txt?r1=53568&r2=53567

Exclude all ResourceDispatcherHostTest

BUG=50002
TEST=none

Review URL: http://codereview.chromium.org/3009023
------------------------------------------------------------------------

Fix is here:
http://codereview.chromium.org/3052014

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=53820 

------------------------------------------------------------------------
r53820 | darin@chromium.org | 2010-07-27 12:28:12 -0700 (Tue, 27 Jul 2010) | 12 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/resource_dispatcher_host_unittest.cc?r1=53820&r2=53819
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/valgrind/unit_tests.gtest_mac.txt?r1=53820&r2=53819

Fix unit tests for the ResourceDispatcherHost.

A field of the ViewHostMsg_Resource_Request structure was uninitialized.

Also, includes a fix for an ASSERT_EQ that listed the expected value second
instead of first.

R=oshima
BUG=50002
TEST=none

Review URL: http://codereview.chromium.org/3052014
------------------------------------------------------------------------

(No comment was entered for this change.)

Given that we branched for M6 @r53024, and the regression went in @r53378, it looks like it should be unnecessary to backport this to the M6 (472) branch.

Verifier Updated by AutoAllocator, contact AmolK or KrisR for questions

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

This is introduced between 53415 - 53406 (http://build.chromium.org/buildbot/memory/builders/Chromium%20Mac%20(valgrind)/builds/6676)
I doubt it's sky, jhawkis, thestig, petkov or me. I talked to jay and he said it's unlikely. Since this is IPC related, i guess it's probably 53415.
jschuh, could you please look into this? Please feel free to assign back to me if you think it's not yours.

Conditional jump or move depends on uninitialised value(s)
  Pickle::ReadBool(void**, bool*) const
  IPC::ParamTraits<ViewHostMsg_Resource_Request>::Read(IPC::Message const*, void**, ViewHostMsg_Resource_Request*)
  IPC::ParamTraits<Tuple2<int, ViewHostMsg_Resource_Request> >::Read(IPC::Message const*, void**, Tuple2<int, ViewHostMsg_Resource_Request>*)
  IPC::MessageWithTuple<Tuple2<int, ViewHostMsg_Resource_Request> >::Read(IPC::Message const*, Tuple2<int, ViewHostMsg_Resource_Request>*)
  bool IPC::MessageWithTuple<Tuple2<int, ViewHostMsg_Resource_Request> >::Dispatch<ResourceDispatcherHost, int, ViewHostMsg_Resource_Request const&>(IPC::Message const*, ResourceDispatcherHost*, void (ResourceDispatcherHost::*)(IPC::Message const&, int, ViewHostMsg_Resource_Request const&))
  ResourceDispatcherHost::OnMessageReceived(IPC::Message const&, ResourceDispatcherHost::Receiver*, bool*)
  ResourceDispatcherHostTest::MakeTestRequest(ResourceDispatcherHost::Receiver*, int, int, GURL const&)
  ResourceDispatcherHostTest_TestMany_Test::TestBody()
  testing::Test::Run()
  testing::internal::TestInfoImpl::Run()
  testing::TestCase::Run()
  testing::internal::UnitTestImpl::RunAllTests()
  TestSuite::Run()
  main
Suppression:
{
   <insert_a_suppression_name_here>
   Memcheck:Cond
   fun:_ZNK6Pickle8ReadBoolEPPvPb
   fun:_ZN3IPC11ParamTraitsI28ViewHostMsg_Resource_RequestE4ReadEPKNS_7MessageEPPvPS1_
   fun:_ZN3IPC11ParamTraitsI6Tuple2Ii28ViewHostMsg_Resource_RequestEE4ReadEPKNS_7MessageEPPvPS3_
   fun:_ZN3IPC16MessageWithTupleI6Tuple2Ii28ViewHostMsg_Resource_RequestEE4ReadEPKNS_7MessageEPS3_
   fun:_ZN3IPC16MessageWithTupleI6Tuple2Ii28ViewHostMsg_Resource_RequestEE8DispatchI22ResourceDispatcherHostiRKS2_EEbPKNS_7MessageEPT_MSC_FvRSA_T0_T1_E
   fun:_ZN22ResourceDispatcherHost17OnMessageReceivedERKN3IPC7MessageEPNS_8ReceiverEPb
   fun:_ZN26ResourceDispatcherHostTest15MakeTestRequestEPN22ResourceDispatcherHost8ReceiverEiiRK4GURL
   fun:_ZN40ResourceDispatcherHostTest_TestMany_Test8TestBodyEv
   fun:_ZN7testing4Test3RunEv
   fun:_ZN7testing8internal12TestInfoImpl3RunEv
   fun:_ZN7testing8TestCase3RunEv
   fun:_ZN7testing8internal12UnitTestImpl11RunAllTestsEv
   fun:_ZN9TestSuite3RunEv
   fun:mai

This is introduced between 53415 - 53406 (http://build.chromium.org/buildbot/memory/builders/Chromium%20Mac%20(valgrind)/builds/6676)
I doubt it's sky, jhawkis, thestig, petkov or me. I talked to jay and he said it's unlikely. Since this is IPC related, i guess it's probably 53415.
jschuh, could you please look into this? Please feel free to assign back to me if you think it's not yours.

Conditional jump or move depends on uninitialised value(s)
  Pickle::ReadBool(void**, bool*) const
  IPC::ParamTraits<ViewHostMsg_Resource_Request>::Read(IPC::Message const*, void**, ViewHostMsg_Resource_Request*)
  IPC::ParamTraits<Tuple2<int, ViewHostMsg_Resource_Request> >::Read(IPC::Message const*, void**, Tuple2<int, ViewHostMsg_Resource_Request>*)
  IPC::MessageWithTuple<Tuple2<int, ViewHostMsg_Resource_Request> >::Read(IPC::Message const*, Tuple2<int, ViewHostMsg_Resource_Request>*)
  bool IPC::MessageWithTuple<Tuple2<int, ViewHostMsg_Resource_Request> >::Dispatch<ResourceDispatcherHost, int, ViewHostMsg_Resource_Request const&>(IPC::Message const*, ResourceDispatcherHost*, void (ResourceDispatcherHost::*)(IPC::Message const&, int, ViewHostMsg_Resource_Request const&))
  ResourceDispatcherHost::OnMessageReceived(IPC::Message const&, ResourceDispatcherHost::Receiver*, bool*)
  ResourceDispatcherHostTest::MakeTestRequest(ResourceDispatcherHost::Receiver*, int, int, GURL const&)
  ResourceDispatcherHostTest_TestMany_Test::TestBody()
  testing::Test::Run()
  testing::internal::TestInfoImpl::Run()
  testing::TestCase::Run()
  testing::internal::UnitTestImpl::RunAllTests()
  TestSuite::Run()
  main
Suppression:
{
   <insert_a_suppression_name_here>
   Memcheck:Cond
   fun:_ZNK6Pickle8ReadBoolEPPvPb
   fun:_ZN3IPC11ParamTraitsI28ViewHostMsg_Resource_RequestE4ReadEPKNS_7MessageEPPvPS1_
   fun:_ZN3IPC11ParamTraitsI6Tuple2Ii28ViewHostMsg_Resource_RequestEE4ReadEPKNS_7MessageEPPvPS3_
   fun:_ZN3IPC16MessageWithTupleI6Tuple2Ii28ViewHostMsg_Resource_RequestEE4ReadEPKNS_7MessageEPS3_
   fun:_ZN3IPC16MessageWithTupleI6Tuple2Ii28ViewHostMsg_Resource_RequestEE8DispatchI22ResourceDispatcherHostiRKS2_EEbPKNS_7MessageEPT_MSC_FvRSA_T0_T1_E
   fun:_ZN22ResourceDispatcherHost17OnMessageReceivedERKN3IPC7MessageEPNS_8ReceiverEPb
   fun:_ZN26ResourceDispatcherHostTest15MakeTestRequestEPN22ResourceDispatcherHost8ReceiverEiiRK4GURL
   fun:_ZN40ResourceDispatcherHostTest_TestMany_Test8TestBodyEv
   fun:_ZN7testing4Test3RunEv
   fun:_ZN7testing8internal12TestInfoImpl3RunEv
   fun:_ZN7testing8TestCase3RunEv
   fun:_ZN7testing8internal12UnitTestImpl11RunAllTestsEv
   fun:_ZN9TestSuite3RunEv
   fun:mai

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)