We do boot with /3GB on the bots already. I talked with M-A about /LARGEADDRESSAWARE and apparently in the past we've had issues with it and the sandbox and v8, so we're not using it anywhere. It's possible that those issues have been addressed since the last time M-A looked into this, but verifying that is a fair amount of work.
Erik On Wed, Aug 19, 2009 at 7:26 PM, Nick Carter<[email protected]> wrote: > Would a quick fix of /3GB in the boot.ini and /LARGEADDRESSAWARE on the > linker cmdline be viable, or are we already doing that? > > - nick > > 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 -~----------~----~----~----~------~----~------~--~---
