Sometimes all you have to do is send an email saying that you give up in order to find a solution. ;-)
I did a little more poking around last night and found one test (SpellCheckTest.SpellCheckText, which only recently landed) that was contributing 300-400MB of private bytes to the address space of the process (likely a Purify issue, not anything wrong with the test itself). Disabling this test allows unit_tests.exe to complete again and likely gives us a few more months of breathing room. http://crbug.com/19833 http://crbug.com/19834 Erik On Wed, Aug 19, 2009 at 4:12 PM, Erik Kay<[email protected]> wrote: > The XP unit Purify bot has been failing for the last week or so. > Unfortunately, this has turned out to be more than just a simple case > where we can filter out a particular broken test. To fix it, we > either need a fix from IBM/Rational (unlikely, due to the nature of > the bug - see below), or we need to do a bit of surgery on the test > itself. Huan has agreed to help with the latter, but this will likely > take some time to work out. In the meantime, we're more vulnerable to > new memory bugs. Please do your best to be extra careful until we can > get the bot enabled again. When we do enable the bot, we should > expect to have a number of new bugs that need to be looked at in short > order. > > We'll give more updates as we have them. > > Erik > > Details for those who care: > > The issue appears to be that unit_tests.exe under Purify is running > out of address space. I spent some time over the past few days > disabling tests hoping that the failure was specific to some > particular test. Unfortunately it seems that the issue is just that > unit_tests.exe has gotten too large. Purify keeps a bunch of > accounting data for warnings and errors in memory. It even keeps > records for errors that are filtered out. Microsoft's STL > implementation generates many warnings (primarily UMRs), and we use > STL heavily (from Rational's and our analysis, these warnings appear > to be benign). Each of these warnings slows down Purify execution and > consume (a fairly large amount of) memory. We now appear to have > enough tests that generate enough warnings that we're running out of > memory from them. > > So the approach Huan's looking into now is to run unit_tests.exe in > chunks similar to how we do layout and ui tests (although it would run > all chunks in one build rather than split across multiple runs). The > other approach would involve splitting unit_tests.exe into smaller > pieces (browser, renderer, common, etc.). This could have other > benefits potentially as the executable size would be smaller, which > would have faster iteration cycles (faster link times, faster > instrumentation times, etc.). Let me know if you have any interest in > doing work with this approach. > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
