The main issue I had with splitting unit_tests is the porosity between chrome/browser and chrome/renderer. There's way too much direct calls between both. http://code.google.com/p/chromium/issues/detail?id=4301
M-A On Wed, Aug 19, 2009 at 11:25 PM, Lei Zhang <[email protected]> wrote: > > +1 for splitting unit_tests. On Linux, it's possible to generate a > 2.3GB unit_tests binary that won't run. X-( > > 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 -~----------~----~----~----~------~----~------~--~---
