Re: [chromium-dev] Extension for context menu?
No time frame, though they keep it in mind for the future. ☆PhistucK On Tue, Dec 1, 2009 at 21:27, est wrote: > Hi chomium-dev, > > When could we add context menu items in an extension? I really which > at least there would be something like FlashGot or DownloadThemAll for > Chrome. > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: >http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Design doc: Geolocation
I'd expect the icons in the mocks to be BSD licensed, which means you'd be free to use them in Firefox if you liked them. Does Firefox already have Geolocation iconography that we should consider? The right folks to get on board are the members of the UI team. Glen's probably the right person to start with. Adam On Tue, Dec 1, 2009 at 3:07 PM, Alex Faaborg wrote: > Should the various browser vendors try to use common iconography for > geolocation, similar to how a standard symbol for Web Feeds emerged? The > external consistency would likely help users as they moved between multiple > apps and sites that support geolocation. > -Alex > > On Nov 28, 2009, at 5:07 PM, Adam Barth wrote: > >> Nice mocks. A few questions: >> >> 1) Why green? The other infobars in the product are yellow. >> Historically, green in browsers has signaled extended validation. >> >> 2) Is there any difference in presentation for SSL versus non-SSL >> sites? From the mocks, it looks like we're showing the host name but >> not the scheme. >> >> 3) Will there be an option to dismiss these dialogs for good (either >> to accept them all or reject them all)? >> >> Thanks, >> Adam >> >> >> On Thu, Nov 26, 2009 at 10:03 AM, Jonathan Dixon >> wrote: >>> >>> I am implementung the geolocation API >>> (http://www.w3.org/TR/geolocation-API/) in Chromium using the WebKit >>> native >>> bindings. Here is a short design doc for the changes: >>> http://docs.google.com/View?id=dfbnm49n_0dpc7pxpx >>> >>> If you have any comments or questions please feel free to direct them to >>> me. >>> >>> Cheers >>> Jonathan >>> >>> -- >>> Chromium Developers mailing list: chromium-dev@googlegroups.com >>> View archives, change email options, or unsubscribe: >>> http://groups.google.com/group/chromium-dev >> >> -- >> Chromium Developers mailing list: chromium-dev@googlegroups.com >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev > > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: WorkerTest in the linux/valgrind tests are silently failing due to mmap failure
# Re-sending b/c gmail didn't use my account properly. Sorry if you get this twice. On Tue, Dec 1, 2009 at 3:53 PM, David Levin wrote: > > > On Tue, Dec 1, 2009 at 2:30 PM, oshima wrote: > >> Looks like there are more tests that failing in valgrind test. >> >> shard=1 id=1513 >> [ FAILED ] WorkerTest.MultipleWorkers (103254 ms) >> [ FAILED ] NewTabUITest.ChromeInternalLoadsNTP (74002 ms) >> [ FAILED ] ChromeMainTest.AppLaunch (36539 ms) >> shard=2 id=1916 >> [ FAILED ] WorkerTest.IncognitoSharedWorkers (181154 ms) >> [ FAILED ] SessionHistoryTest.FLAKY_LocationReplace (48297 ms) >> shard=3 id=1761 >> [ FAILED ] WorkerTest.SharedWorkerFastLayoutTests (731911 ms) >> [ FAILED ] AutomationProxyTest.NavigateToURLWithTimeout1 (42516 ms) >> shard=4 id=2075 >> [ FAILED ] WorkerTest.WorkerHttpLayoutTests (119981 ms) >> [ FAILED ] AutomationProxyTest.NavigateToURLWithTimeout2 (36359 ms) >> [ FAILED ] UnloadTest.CrossSiteInfiniteBeforeUnloadSync (342050 ms) >> [ FAILED ] MetricsServiceTest.CrashRenderers (49324 ms) >> >> This is not good. Is there any issue if we make a valgrind test fail when >> the test itself fails? >> If not, I'd suggest that we exclude them in ui_tetsts.gtext.txt for now >> (I'll file bugs) >> and change the test script so that a valgrind test fails when the test >> itself tails. >> Any opinion? >> >> > My quick read of this makes it sounds like you're planning to > disable various tests (like WorkerTests which can easily get broken due to > webkit changes) so that *they don't run at all* simply because valgrind > can't seem to run it. Please don't do that. > > No. This is just for valgrind tests. > If you're going to do changes to scripts and such, maybe you can change it > so that valgrind has some additional skip list. > > Yes that's what I'm going to do. See chrome/test/data/valgrind/ui_tests.gtest.txt - oshima > Thanks, > Dave > > - oshima >> On Fri, Nov 20, 2009 at 12:25 PM, Mitsuru Oshima wrote: >> >>> Hi, >>> >>> I noticed, while working on enabling valgrind test on linux/views, that >>> some of WorkerTest of ui tests in Linux Tests (valgrind) buildbot >>> are failing due to mmap failure.I tested locally with valgrind I >>> built using the script under tools/valgrind (with regular ld, but not gold), >>> and I got the same/similar mmap errors. I did quick search on bug db, but >>> couldn't find it. I'm going to file a bug, but does anyone know about this >>> problem? >>> >>> - oshima >>> >>> [==] Running 37 tests from 23 test cases. >>> [--] Global test environment set-up. >>> [--] 2 tests from WorkerTest >>> [ RUN ] WorkerTest.SingleWorker >>> [8072:8072:1120/090807:5253075177881:INFO:/b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/test/ui/ui_test.cc(1126)] >>> BROWSER_WRAPPER was set, prefixing command_line with >>> /b/slave/chromium-rel-linux-valgrind-tests-1/build/valgrind.tmp/browser_wrapper.ohLiPE >>> valgrind: mmap(0x3800, 1871872) failed in UME with error 22 (Invalid >>> argument). >>> valgrind: this can be caused by executables with very large text, data or >>> bss segments. >>> /b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/worker/worker_uitest.cc:28: >>> Failure >>> Value of: value.c_str() >>> Actual: "" >>> Expected: kTestCompleteSuccess >>> Which is: "OK" >>> [8078:8078:5253178758444:ERROR:/b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/browser/automation/automation_provider.cc(957)] >>> AutomationProxy went away, shutting down app. >>> [ FAILED ] WorkerTest.SingleWorker (109607 ms) >>> >> >> -- >> Chromium Developers mailing list: chromium-dev@googlegroups.com >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev >> > > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Mac10.5 Tests, revision 33526
Automatically closing tree for "unit_tests" on "Mac10.5 Tests" http://build.chromium.org/buildbot/waterfall/builders/Mac10.5%20Tests/builds/9177 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Mac10.5%20Tests --=> Automatically closing tree for "unit_tests" on "Mac10.5 Tests" <=-- Revision: 33526 Blame list: t...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Design doc: Geolocation
On Tue, Dec 1, 2009 at 4:13 PM, Glen Murphy wrote: >> 1) Why green? The other infobars in the product are yellow. >> Historically, green in browsers has signaled extended validation. > > We had intended to use a few differently-colored infobars for a while, > but a more recent discussion (which got out of sync with the geo team; > my fault) has trimmed it to two - a neutral color (chrome blue) and > yellow. The latter being used for errors and warnings, the former for > more functional messages like this. What about users who are using themes? (On Mac and Linux, the neutral color is typically gray, not blue.) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Design doc: Geolocation
> 1) Why green? The other infobars in the product are yellow. > Historically, green in browsers has signaled extended validation. We had intended to use a few differently-colored infobars for a while, but a more recent discussion (which got out of sync with the geo team; my fault) has trimmed it to two - a neutral color (chrome blue) and yellow. The latter being used for errors and warnings, the former for more functional messages like this. > 2) Is there any difference in presentation for SSL versus non-SSL > sites? From the mocks, it looks like we're showing the host name but > not the scheme. > > 3) Will there be an option to dismiss these dialogs for good (either > to accept them all or reject them all)? -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: WorkerTest in the linux/valgrind tests are silently failing due to mmap failure
That is excellent! I didn't know there was such a thing. Thanks, Dave On Tue, Dec 1, 2009 at 4:09 PM, oshima wrote: > # Re-sending b/c gmail didn't use my account properly. Sorry if you get > this twice. > > On Tue, Dec 1, 2009 at 3:53 PM, David Levin wrote: > >> >> >> On Tue, Dec 1, 2009 at 2:30 PM, oshima wrote: >> >>> Looks like there are more tests that failing in valgrind test. >>> >>> shard=1 id=1513 >>> [ FAILED ] WorkerTest.MultipleWorkers (103254 ms) >>> [ FAILED ] NewTabUITest.ChromeInternalLoadsNTP (74002 ms) >>> [ FAILED ] ChromeMainTest.AppLaunch (36539 ms) >>> shard=2 id=1916 >>> [ FAILED ] WorkerTest.IncognitoSharedWorkers (181154 ms) >>> [ FAILED ] SessionHistoryTest.FLAKY_LocationReplace (48297 ms) >>> shard=3 id=1761 >>> [ FAILED ] WorkerTest.SharedWorkerFastLayoutTests (731911 ms) >>> [ FAILED ] AutomationProxyTest.NavigateToURLWithTimeout1 (42516 ms) >>> shard=4 id=2075 >>> [ FAILED ] WorkerTest.WorkerHttpLayoutTests (119981 ms) >>> [ FAILED ] AutomationProxyTest.NavigateToURLWithTimeout2 (36359 ms) >>> [ FAILED ] UnloadTest.CrossSiteInfiniteBeforeUnloadSync (342050 ms) >>> [ FAILED ] MetricsServiceTest.CrashRenderers (49324 ms) >>> >>> This is not good. Is there any issue if we make a valgrind test fail when >>> the test itself fails? >>> If not, I'd suggest that we exclude them in ui_tetsts.gtext.txt for now >>> (I'll file bugs) >>> and change the test script so that a valgrind test fails when the test >>> itself tails. >>> Any opinion? >>> >>> >> My quick read of this makes it sounds like you're planning to >> disable various tests (like WorkerTests which can easily get broken due to >> webkit changes) so that *they don't run at all* simply because valgrind >> can't seem to run it. Please don't do that. >> >> No. This is just for valgrind tests. > > >> If you're going to do changes to scripts and such, maybe you can change it >> so that valgrind has some additional skip list. >> >> > Yes that's what I'm going to do. See > chrome/test/data/valgrind/ui_tests.gtest.txt > > - oshima > > >> Thanks, >> Dave >> >> - oshima >>> On Fri, Nov 20, 2009 at 12:25 PM, Mitsuru Oshima wrote: >>> Hi, I noticed, while working on enabling valgrind test on linux/views, that some of WorkerTest of ui tests in Linux Tests (valgrind) buildbot are failing due to mmap failure.I tested locally with valgrind I built using the script under tools/valgrind (with regular ld, but not gold), and I got the same/similar mmap errors. I did quick search on bug db, but couldn't find it. I'm going to file a bug, but does anyone know about this problem? - oshima [==] Running 37 tests from 23 test cases. [--] Global test environment set-up. [--] 2 tests from WorkerTest [ RUN ] WorkerTest.SingleWorker [8072:8072:1120/090807:5253075177881:INFO:/b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/test/ui/ui_test.cc(1126)] BROWSER_WRAPPER was set, prefixing command_line with /b/slave/chromium-rel-linux-valgrind-tests-1/build/valgrind.tmp/browser_wrapper.ohLiPE valgrind: mmap(0x3800, 1871872) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. /b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/worker/worker_uitest.cc:28: Failure Value of: value.c_str() Actual: "" Expected: kTestCompleteSuccess Which is: "OK" [8078:8078:5253178758444:ERROR:/b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/browser/automation/automation_provider.cc(957)] AutomationProxy went away, shutting down app. [ FAILED ] WorkerTest.SingleWorker (109607 ms) >>> >>> -- >>> Chromium Developers mailing list: chromium-dev@googlegroups.com >>> View archives, change email options, or unsubscribe: >>> http://groups.google.com/group/chromium-dev >>> >> >> > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: WorkerTest in the linux/valgrind tests are silently failing due to mmap failure
On Tue, Dec 1, 2009 at 2:30 PM, oshima wrote: > Looks like there are more tests that failing in valgrind test. > > shard=1 id=1513 > [ FAILED ] WorkerTest.MultipleWorkers (103254 ms) > [ FAILED ] NewTabUITest.ChromeInternalLoadsNTP (74002 ms) > [ FAILED ] ChromeMainTest.AppLaunch (36539 ms) > shard=2 id=1916 > [ FAILED ] WorkerTest.IncognitoSharedWorkers (181154 ms) > [ FAILED ] SessionHistoryTest.FLAKY_LocationReplace (48297 ms) > shard=3 id=1761 > [ FAILED ] WorkerTest.SharedWorkerFastLayoutTests (731911 ms) > [ FAILED ] AutomationProxyTest.NavigateToURLWithTimeout1 (42516 ms) > shard=4 id=2075 > [ FAILED ] WorkerTest.WorkerHttpLayoutTests (119981 ms) > [ FAILED ] AutomationProxyTest.NavigateToURLWithTimeout2 (36359 ms) > [ FAILED ] UnloadTest.CrossSiteInfiniteBeforeUnloadSync (342050 ms) > [ FAILED ] MetricsServiceTest.CrashRenderers (49324 ms) > > This is not good. Is there any issue if we make a valgrind test fail when > the test itself fails? > If not, I'd suggest that we exclude them in ui_tetsts.gtext.txt for now > (I'll file bugs) > and change the test script so that a valgrind test fails when the test > itself tails. > Any opinion? > > My quick read of this makes it sounds like you're planning to disable various tests (like WorkerTests which can easily get broken due to webkit changes) so that *they don't run at all* simply because valgrind can't seem to run it. Please don't do that. If you're going to do changes to scripts and such, maybe you can change it so that valgrind has some additional skip list. Thanks, Dave - oshima > On Fri, Nov 20, 2009 at 12:25 PM, Mitsuru Oshima wrote: > >> Hi, >> >> I noticed, while working on enabling valgrind test on linux/views, that >> some of WorkerTest of ui tests in Linux Tests (valgrind) buildbot >> are failing due to mmap failure.I tested locally with valgrind I >> built using the script under tools/valgrind (with regular ld, but not gold), >> and I got the same/similar mmap errors. I did quick search on bug db, but >> couldn't find it. I'm going to file a bug, but does anyone know about this >> problem? >> >> - oshima >> >> [==] Running 37 tests from 23 test cases. >> [--] Global test environment set-up. >> [--] 2 tests from WorkerTest >> [ RUN ] WorkerTest.SingleWorker >> [8072:8072:1120/090807:5253075177881:INFO:/b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/test/ui/ui_test.cc(1126)] >> BROWSER_WRAPPER was set, prefixing command_line with >> /b/slave/chromium-rel-linux-valgrind-tests-1/build/valgrind.tmp/browser_wrapper.ohLiPE >> valgrind: mmap(0x3800, 1871872) failed in UME with error 22 (Invalid >> argument). >> valgrind: this can be caused by executables with very large text, data or >> bss segments. >> /b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/worker/worker_uitest.cc:28: >> Failure >> Value of: value.c_str() >> Actual: "" >> Expected: kTestCompleteSuccess >> Which is: "OK" >> [8078:8078:5253178758444:ERROR:/b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/browser/automation/automation_provider.cc(957)] >> AutomationProxy went away, shutting down app. >> [ FAILED ] WorkerTest.SingleWorker (109607 ms) >> > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Design doc: Geolocation
On Tue, Dec 1, 2009 at 6:07 PM, Alex Faaborg wrote: > Should the various browser vendors try to use common iconography for > geolocation, similar to how a standard symbol for Web Feeds emerged? > The external consistency would likely help users as they moved between > multiple apps and sites that support geolocation. > -Alex > I would like that. One thing I liked about the icon for RSS is that its consistent. On Nov 28, 2009, at 5:07 PM, Adam Barth wrote: > > > Nice mocks. A few questions: > > > > 1) Why green? The other infobars in the product are yellow. > > Historically, green in browsers has signaled extended validation. > > > > 2) Is there any difference in presentation for SSL versus non-SSL > > sites? From the mocks, it looks like we're showing the host name but > > not the scheme. > > > > 3) Will there be an option to dismiss these dialogs for good (either > > to accept them all or reject them all)? > > > > Thanks, > > Adam > > > > > > On Thu, Nov 26, 2009 at 10:03 AM, Jonathan Dixon > > wrote: > >> I am implementung the geolocation API > >> (http://www.w3.org/TR/geolocation-API/) in Chromium using the > >> WebKit native > >> bindings. Here is a short design doc for the changes: > >> http://docs.google.com/View?id=dfbnm49n_0dpc7pxpx > >> > >> If you have any comments or questions please feel free to direct > >> them to me. > >> > >> Cheers > >> Jonathan > >> > >> -- > >> Chromium Developers mailing list: chromium-dev@googlegroups.com > >> View archives, change email options, or unsubscribe: > >> http://groups.google.com/group/chromium-dev > > > > -- > > Chromium Developers mailing list: chromium-dev@googlegroups.com > > View archives, change email options, or unsubscribe: > >http://groups.google.com/group/chromium-dev > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: >http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: WorkerTest in the linux/valgrind tests are silently failing due to mmap failure
On Tue, Dec 1, 2009 at 2:30 PM, oshima wrote: > Looks like there are more tests that failing in valgrind test. > ... > This is not good. Is there any issue if we make a valgrind test fail when > the test itself fails? > If not, I'd suggest that we exclude them in ui_tetsts.gtext.txt for now > (I'll file bugs) > and change the test script so that a valgrind test fails when the test > itself tails. > Any opinion? It's a great idea. This (and getting more tests to pass under valgrind) has been on Stuart's post-beta to-do list for some time. If somebody else wants to beat him to it, I'm sure he wouldn't complain... - Dan -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Design doc: Geolocation
Should the various browser vendors try to use common iconography for geolocation, similar to how a standard symbol for Web Feeds emerged? The external consistency would likely help users as they moved between multiple apps and sites that support geolocation. -Alex On Nov 28, 2009, at 5:07 PM, Adam Barth wrote: > Nice mocks. A few questions: > > 1) Why green? The other infobars in the product are yellow. > Historically, green in browsers has signaled extended validation. > > 2) Is there any difference in presentation for SSL versus non-SSL > sites? From the mocks, it looks like we're showing the host name but > not the scheme. > > 3) Will there be an option to dismiss these dialogs for good (either > to accept them all or reject them all)? > > Thanks, > Adam > > > On Thu, Nov 26, 2009 at 10:03 AM, Jonathan Dixon > wrote: >> I am implementung the geolocation API >> (http://www.w3.org/TR/geolocation-API/) in Chromium using the >> WebKit native >> bindings. Here is a short design doc for the changes: >> http://docs.google.com/View?id=dfbnm49n_0dpc7pxpx >> >> If you have any comments or questions please feel free to direct >> them to me. >> >> Cheers >> Jonathan >> >> -- >> Chromium Developers mailing list: chromium-dev@googlegroups.com >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: >http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: WorkerTest in the linux/valgrind tests are silently failing due to mmap failure
Looks like there are more tests that failing in valgrind test. shard=1 id=1513 [ FAILED ] WorkerTest.MultipleWorkers (103254 ms) [ FAILED ] NewTabUITest.ChromeInternalLoadsNTP (74002 ms) [ FAILED ] ChromeMainTest.AppLaunch (36539 ms) shard=2 id=1916 [ FAILED ] WorkerTest.IncognitoSharedWorkers (181154 ms) [ FAILED ] SessionHistoryTest.FLAKY_LocationReplace (48297 ms) shard=3 id=1761 [ FAILED ] WorkerTest.SharedWorkerFastLayoutTests (731911 ms) [ FAILED ] AutomationProxyTest.NavigateToURLWithTimeout1 (42516 ms) shard=4 id=2075 [ FAILED ] WorkerTest.WorkerHttpLayoutTests (119981 ms) [ FAILED ] AutomationProxyTest.NavigateToURLWithTimeout2 (36359 ms) [ FAILED ] UnloadTest.CrossSiteInfiniteBeforeUnloadSync (342050 ms) [ FAILED ] MetricsServiceTest.CrashRenderers (49324 ms) This is not good. Is there any issue if we make a valgrind test fail when the test itself fails? If not, I'd suggest that we exclude them in ui_tetsts.gtext.txt for now (I'll file bugs) and change the test script so that a valgrind test fails when the test itself tails. Any opinion? - oshima On Fri, Nov 20, 2009 at 12:25 PM, Mitsuru Oshima wrote: > Hi, > > I noticed, while working on enabling valgrind test on linux/views, that > some of WorkerTest of ui tests in Linux Tests (valgrind) buildbot > are failing due to mmap failure.I tested locally with valgrind I > built using the script under tools/valgrind (with regular ld, but not gold), > and I got the same/similar mmap errors. I did quick search on bug db, but > couldn't find it. I'm going to file a bug, but does anyone know about this > problem? > > - oshima > > [==] Running 37 tests from 23 test cases. > [--] Global test environment set-up. > [--] 2 tests from WorkerTest > [ RUN ] WorkerTest.SingleWorker > [8072:8072:1120/090807:5253075177881:INFO:/b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/test/ui/ui_test.cc(1126)] > BROWSER_WRAPPER was set, prefixing command_line with > /b/slave/chromium-rel-linux-valgrind-tests-1/build/valgrind.tmp/browser_wrapper.ohLiPE > valgrind: mmap(0x3800, 1871872) failed in UME with error 22 (Invalid > argument). > valgrind: this can be caused by executables with very large text, data or > bss segments. > /b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/worker/worker_uitest.cc:28: > Failure > Value of: value.c_str() > Actual: "" > Expected: kTestCompleteSuccess > Which is: "OK" > [8078:8078:5253178758444:ERROR:/b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/browser/automation/automation_provider.cc(957)] > AutomationProxy went away, shutting down app. > [ FAILED ] WorkerTest.SingleWorker (109607 ms) > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] NaCl related build error
Hmmn, ok builds for me at the command line. I'll drop by in a bit. -BradN On Tue, Dec 1, 2009 at 11:00 AM, Bradley Nelson wrote: > Hi Antony, > > My fixes arrived at 33433. Did you sync that before trying the above? > I hadn't validated command line builds (I'm checking that myself now). > > Oh by the way, I assume you're using /Out because of devenv.exe 's weird > console piping behavior. > Something we learned with the bots is that if you use devenv.com, normal > piping works correctly, ie you can use |less. > > So there were 2 core problems that I've patched up, but which need to be > done properly, and a 3rd which was fixed about a week ago: > > 1. For ~1-2 months now, there has been an issue in which gyp generates > different vcproj files (some slashes flipped the wrong way) when run under > cygwin (this got broke at some point). This does not actually affect all > cygwin users, because of the behavior of depot_tools. Historically > depot_tools installed its own python, which took precedence over cygwin > python. This meant that if you used gclient runhooks, you'd always be using > win32 python. At some point in the last 3 months or so, depot_tools was > changed, so that it only installs its own python if one is not already in > the path. So cygwin users who have cygwin python installed at the time they > first installed depot_tools, will end up using gyp with cygwin python. These > cygwin generated vcproj files fail for several modules, notably nacl. > I've corrected this in a somewhat hacky way, but the two now are basically > identical. > > 2. Nacl currently makes extensive use of msvs_cygwin_shell: 0. This option > in gyp was intended to allow direct access to cmd on windows. Most targets > in chrome with actions/rules do not use this option. This option was > intended as a backdoor for things like running setup_mount to get the > hermetic cygwin initialized. Unfortunately, nacl's scons build made > extensive use of scons's more flexible command line handling. > In transitioning to gyp, several command lines where handled by using > conditionals on platform, and using platform specific piping etc. > msvs_cygwin_shell: 0, makes no attempt to setup cygwin or python in the > path. As a result, at some point nacl folks added PYTHON_EXE, wrapper > scripts, and other gyp variables to 'fix' the problem. These scripts didn't > take into account the possibility that devenv.exe could be invoke with > cygwin stuff in the path, and so fail when devenv is started from the > command line. I've corrected these scripts so that they work in the presence > of cygwin. This is, however, a stopgap. What really needs to happen is that > all actions/rules in nacl's gyp files should NOT use msvs_cygwin_shell. This > will mean adding some additional python wrapper scripts / changing the > assumption in existing scripts that the build system is capable of handling > piping. > > 3. A little while back we had a miscommunication about output directories. > Nacl has started generating 32 and 64 bit output. A change went into nacl's > common.gypi which causes output to go to Debug-Win32 / Debug-x64. Since none > of chrome's infrastructure knows to clobber these directories, incremental > builds can hide problems. This got fixed about a week ago. So all the output > should be under Debug. > > So far so good on the command line build I started at the beginning of this > email. I'll drop by and see if you're still hitting issues this afternoon. > > -BradN > > > > On Tue, Dec 1, 2009 at 9:39 AM, Brad Chen wrote: > >> [+ilewis] >> >> I'm happy to hear the Visual Studio GUI build is working; I think this was >> the fix Brad Nelson submitted yesterday. I don't think we've tested a build >> using a script such as you suggest. We're checking it out now. >> >> I apologize for the disruption. The diversity of ways people build on >> Windows and Linux is challenging, and we have difficulty supporting kinds of >> builds we don't know about. The Chrome Windows build looks greenish. It's >> much easier for my team to support Windows/Linux build environments if they >> are represented in the buildbots. If somebody has ideas for how this >> specific issue can be better represented in the Chrome buildbots I'm very >> interested. >> >> Brad >> >> On Tue, Dec 1, 2009 at 9:24 AM, Antony Sargent wrote: >> >>> I've tried a few combinations of deleting my Debug directory and running >>> "gclient runhooks", and I *think* I've narrowed the problem down to the >>> build failing if do a command-line build, but working ok if I build from >>> within the Visual Studio GUI. The script I have which does the (now failing) >>> command line build does: >>> >>> devenv.exe chrome.sln /Build Debug /Out C:\\tmp\\build.log /Project >>> chrome >>> >>> This worked fine until quite recently. >>> >>> >>> On Tue, Dec 1, 2009 at 12:18 AM, Peter Kasting wrote: >>> On Mon, Nov 30, 2009 at 10:01 PM, Antony Sargent >>> > wrote: > I just updated to revision 334
Re: [chromium-dev] Waiting for things in ResourceDispatcherHost
On Tue, Dec 1, 2009 at 09:09, Darin Fisher wrote: > It might help the discussion if you could toss out a proposal for what you > think might work. > My initial idea is an object (ResourceQueue? ResourceWaitQueue?) that the RDH will ask before starting an URLRequest (similar to how it currently asks UserScriptListener). If the new object says "yes", RDH will start the request immediately. Otherwise the queue object will wait until all interested parties are ready and then start the request (and probably notify RDH, similarly to UserScriptListener). The queue object will know what to wait for and which objects to ask (for example, BlacklistManager object and BLACKLIST_MANAGER_BLACKLIST_READ_FINISHED notification on the IO thread). Two main problems I currently see: - does it generally make sense? - I don't quite like the names. The object I'm talking about isn't really a queue (there is no order). It just manager waiting for parties interested in resource requests. If you have a better idea for the name, that would be great. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Chromium Linux x64, revision 33479
Automatically closing tree for "compile" on "Chromium Linux x64" http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Linux%20x64/builds/3056 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Linux%20x64 --=> Automatically closing tree for "compile" on "Chromium Linux x64" <=-- Revision: 33476, 33477, 33478, 33479 Blame list: fin...@chromium.org,john...@chromium.org,pkast...@chromium.org,viettrung...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] NaCl related build error
I just synced to 33433 and the command line build works for me now. Thanks for looking into this! On Tue, Dec 1, 2009 at 12:13 PM, Bradley Nelson wrote: > Hmmn, ok builds for me at the command line. I'll drop by in a bit. > -BradN > > > On Tue, Dec 1, 2009 at 11:00 AM, Bradley Nelson wrote: > >> Hi Antony, >> >> My fixes arrived at 33433. Did you sync that before trying the above? >> I hadn't validated command line builds (I'm checking that myself now). >> >> Oh by the way, I assume you're using /Out because of devenv.exe 's weird >> console piping behavior. >> Something we learned with the bots is that if you use devenv.com, normal >> piping works correctly, ie you can use |less. >> >> So there were 2 core problems that I've patched up, but which need to be >> done properly, and a 3rd which was fixed about a week ago: >> >> 1. For ~1-2 months now, there has been an issue in which gyp generates >> different vcproj files (some slashes flipped the wrong way) when run under >> cygwin (this got broke at some point). This does not actually affect all >> cygwin users, because of the behavior of depot_tools. Historically >> depot_tools installed its own python, which took precedence over cygwin >> python. This meant that if you used gclient runhooks, you'd always be using >> win32 python. At some point in the last 3 months or so, depot_tools was >> changed, so that it only installs its own python if one is not already in >> the path. So cygwin users who have cygwin python installed at the time they >> first installed depot_tools, will end up using gyp with cygwin python. These >> cygwin generated vcproj files fail for several modules, notably nacl. >> I've corrected this in a somewhat hacky way, but the two now are basically >> identical. >> >> 2. Nacl currently makes extensive use of msvs_cygwin_shell: 0. This option >> in gyp was intended to allow direct access to cmd on windows. Most targets >> in chrome with actions/rules do not use this option. This option was >> intended as a backdoor for things like running setup_mount to get the >> hermetic cygwin initialized. Unfortunately, nacl's scons build made >> extensive use of scons's more flexible command line handling. >> In transitioning to gyp, several command lines where handled by using >> conditionals on platform, and using platform specific piping etc. >> msvs_cygwin_shell: 0, makes no attempt to setup cygwin or python in the >> path. As a result, at some point nacl folks added PYTHON_EXE, wrapper >> scripts, and other gyp variables to 'fix' the problem. These scripts didn't >> take into account the possibility that devenv.exe could be invoke with >> cygwin stuff in the path, and so fail when devenv is started from the >> command line. I've corrected these scripts so that they work in the presence >> of cygwin. This is, however, a stopgap. What really needs to happen is that >> all actions/rules in nacl's gyp files should NOT use msvs_cygwin_shell. This >> will mean adding some additional python wrapper scripts / changing the >> assumption in existing scripts that the build system is capable of handling >> piping. >> >> 3. A little while back we had a miscommunication about output directories. >> Nacl has started generating 32 and 64 bit output. A change went into nacl's >> common.gypi which causes output to go to Debug-Win32 / Debug-x64. Since none >> of chrome's infrastructure knows to clobber these directories, incremental >> builds can hide problems. This got fixed about a week ago. So all the output >> should be under Debug. >> >> So far so good on the command line build I started at the beginning of >> this email. I'll drop by and see if you're still hitting issues this >> afternoon. >> >> -BradN >> >> >> >> On Tue, Dec 1, 2009 at 9:39 AM, Brad Chen wrote: >> >>> [+ilewis] >>> >>> I'm happy to hear the Visual Studio GUI build is working; I think this >>> was the fix Brad Nelson submitted yesterday. I don't think we've tested a >>> build using a script such as you suggest. We're checking it out now. >>> >>> I apologize for the disruption. The diversity of ways people build on >>> Windows and Linux is challenging, and we have difficulty supporting kinds of >>> builds we don't know about. The Chrome Windows build looks greenish. It's >>> much easier for my team to support Windows/Linux build environments if they >>> are represented in the buildbots. If somebody has ideas for how this >>> specific issue can be better represented in the Chrome buildbots I'm very >>> interested. >>> >>> Brad >>> >>> On Tue, Dec 1, 2009 at 9:24 AM, Antony Sargent wrote: >>> I've tried a few combinations of deleting my Debug directory and running "gclient runhooks", and I *think* I've narrowed the problem down to the build failing if do a command-line build, but working ok if I build from within the Visual Studio GUI. The script I have which does the (now failing) command line build does: devenv.exe chrome.sln /Build Debug /Out C
Re: [chromium-dev] Information about revisions
Hi, Anton,
Thanks for the additional information. I tried several points on that graph.
They didn't show any revision information at first, but a few seconds later
the frame loaded. Now I can look at other data points without any delay.
Since it works sometimes, I suspect that the problem is in the network (a
timeout, partial result sent, proxy error, or something of that sort),
rather than an actual bug in the data file or parsing.
What happens if you click the "Show Changelog" button, either with or
without changing the revision range? It should (re)load the svn log for the
range shown.
- Pam
On Tue, Dec 1, 2009 at 12:19 PM, Anton Muhin wrote:
> Good day, Pam.
>
> On Tue, Dec 1, 2009 at 11:13 PM, Pam Greene wrote:
> > Can you be more specific? I gather you mean the revision information at
> the
> > bottom of the performance graphs, when you select a data point on the
> graph.
>
> Precisely, one with SVN path, revision range, etc.
>
> > I just tried one at random (Page Cycle Intl1 - XP Perf) and it seems to
> be
> > working correctly. What exactly causes this error?
>
> I tried
> http://build.chromium.org/buildbot/perf/xp-release-dual-core/intl1/report.html?history=150
> and for several random points (in Chrome, Safari and FF) it shows no
> info for revisions (inside the big test field), it shows revision
> range and pages info (if I click pages on the right). For this URL I
> see no errors in the log.
>
> yours,
> anton.
>
> > On Tue, Dec 1, 2009 at 6:29 AM, Anton Muhin
> wrote:>>
> >> Dear chromiumers,
> >>
> >> Relatively recently I stopped seeing information about revisions for
> >> build bot graphs. If I open our debugger it reports something like:
> >>
> >> Uncaught TypeError: Cannot call method 'slice' of undefined.
> >>
> >> Line number it gives is incorrect. Most probably it should be actually
> >> line 50:
> >>
> >> function received_data(data) {
> >> var tbody = document.getElementById("tbody");
> >> data.replace('\r', '');
> >>
> >> var col_sums = [];
> >> var rows = data.split('\n');
> >>
> >> for (var i = 0; i < rows.length; ++i) {
> >>var tr = document.createElement("TR");
> >>
> >>var cols = rows[i].split(' ');
> >>
> >>// cols[0] = page name
> >>// cols[1] = (mean+/-standard deviation):
> >>// cols[2...] = individual runs
> >>
> >>// Require at least the page name and statistics.
> >>if (cols.length < 2)
> >> continue;
> >>
> >>var page = cols[0];
> >>var values = cols[1].split('+/-');
> >>append_column(tr, page, col_sums, -1);
> >>append_column(tr, values[0].slice(1), col_sums, 0); // HERE WE'RE
> >> FAILING
> >>append_column(tr, values[1].slice(0,-2), col_sums, 1);
> >>
> >>for (var j = 2; j < cols.length; ++j)
> >> append_column(tr, cols[j], col_sums, j);
> >>
> >>tbody.appendChild(tr);
> >> }
> >>
> >> It looks like data are returned in a wrong format. Chances are it is
> >> a problem with DOM or Dromaeo benchmarks, but I cannot see rev info
> >> for other build bots either (e.g. Page Cycler Moz), there is no
> >> exception however.
> >>
> >> Any ideas what goes on?
> >>
> >> yours,
> >> anton.
> >>
> >> --
> >> Chromium Developers mailing list: chromium-dev@googlegroups.com
> >> View archives, change email options, or unsubscribe:
> >>http://groups.google.com/group/chromium-dev
> >
> >
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Information about revisions
Good day, Pam.
On Tue, Dec 1, 2009 at 11:13 PM, Pam Greene wrote:
> Can you be more specific? I gather you mean the revision information at the
> bottom of the performance graphs, when you select a data point on the graph.
Precisely, one with SVN path, revision range, etc.
> I just tried one at random (Page Cycle Intl1 - XP Perf) and it seems to be
> working correctly. What exactly causes this error?
I tried
http://build.chromium.org/buildbot/perf/xp-release-dual-core/intl1/report.html?history=150
and for several random points (in Chrome, Safari and FF) it shows no
info for revisions (inside the big test field), it shows revision
range and pages info (if I click pages on the right). For this URL I
see no errors in the log.
yours,
anton.
> On Tue, Dec 1, 2009 at 6:29 AM, Anton Muhin wrote:>>
>> Dear chromiumers,
>>
>> Relatively recently I stopped seeing information about revisions for
>> build bot graphs. If I open our debugger it reports something like:
>>
>> Uncaught TypeError: Cannot call method 'slice' of undefined.
>>
>> Line number it gives is incorrect. Most probably it should be actually
>> line 50:
>>
>> function received_data(data) {
>> var tbody = document.getElementById("tbody");
>> data.replace('\r', '');
>>
>> var col_sums = [];
>> var rows = data.split('\n');
>>
>> for (var i = 0; i < rows.length; ++i) {
>> var tr = document.createElement("TR");
>>
>> var cols = rows[i].split(' ');
>>
>> // cols[0] = page name
>> // cols[1] = (mean+/-standard deviation):
>> // cols[2...] = individual runs
>>
>> // Require at least the page name and statistics.
>> if (cols.length < 2)
>> continue;
>>
>> var page = cols[0];
>> var values = cols[1].split('+/-');
>> append_column(tr, page, col_sums, -1);
>> append_column(tr, values[0].slice(1), col_sums, 0); // HERE WE'RE
>> FAILING
>> append_column(tr, values[1].slice(0,-2), col_sums, 1);
>>
>> for (var j = 2; j < cols.length; ++j)
>> append_column(tr, cols[j], col_sums, j);
>>
>> tbody.appendChild(tr);
>> }
>>
>> It looks like data are returned in a wrong format. Chances are it is
>> a problem with DOM or Dromaeo benchmarks, but I cannot see rev info
>> for other build bots either (e.g. Page Cycler Moz), there is no
>> exception however.
>>
>> Any ideas what goes on?
>>
>> yours,
>> anton.
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/group/chromium-dev
>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Information about revisions
Can you be more specific? I gather you mean the revision information at the
bottom of the performance graphs, when you select a data point on the graph.
I just tried one at random (Page Cycle Intl1 - XP Perf) and it seems to be
working correctly. What exactly causes this error?
Thanks,
- Pam
On Tue, Dec 1, 2009 at 6:29 AM, Anton Muhin wrote:
> Dear chromiumers,
>
> Relatively recently I stopped seeing information about revisions for
> build bot graphs. If I open our debugger it reports something like:
>
> Uncaught TypeError: Cannot call method 'slice' of undefined.
>
> Line number it gives is incorrect. Most probably it should be actually
> line 50:
>
> function received_data(data) {
> var tbody = document.getElementById("tbody");
> data.replace('\r', '');
>
> var col_sums = [];
> var rows = data.split('\n');
>
> for (var i = 0; i < rows.length; ++i) {
>var tr = document.createElement("TR");
>
>var cols = rows[i].split(' ');
>
>// cols[0] = page name
>// cols[1] = (mean+/-standard deviation):
>// cols[2...] = individual runs
>
>// Require at least the page name and statistics.
>if (cols.length < 2)
> continue;
>
>var page = cols[0];
>var values = cols[1].split('+/-');
>append_column(tr, page, col_sums, -1);
>append_column(tr, values[0].slice(1), col_sums, 0); // HERE WE'RE
> FAILING
>append_column(tr, values[1].slice(0,-2), col_sums, 1);
>
>for (var j = 2; j < cols.length; ++j)
> append_column(tr, cols[j], col_sums, j);
>
>tbody.appendChild(tr);
> }
>
> It looks like data are returned in a wrong format. Chances are it is
> a problem with DOM or Dromaeo benchmarks, but I cannot see rev info
> for other build bots either (e.g. Page Cycler Moz), there is no
> exception however.
>
> Any ideas what goes on?
>
> yours,
> anton.
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] NaCl related build error
Hi Antony, My fixes arrived at 33433. Did you sync that before trying the above? I hadn't validated command line builds (I'm checking that myself now). Oh by the way, I assume you're using /Out because of devenv.exe 's weird console piping behavior. Something we learned with the bots is that if you use devenv.com, normal piping works correctly, ie you can use |less. So there were 2 core problems that I've patched up, but which need to be done properly, and a 3rd which was fixed about a week ago: 1. For ~1-2 months now, there has been an issue in which gyp generates different vcproj files (some slashes flipped the wrong way) when run under cygwin (this got broke at some point). This does not actually affect all cygwin users, because of the behavior of depot_tools. Historically depot_tools installed its own python, which took precedence over cygwin python. This meant that if you used gclient runhooks, you'd always be using win32 python. At some point in the last 3 months or so, depot_tools was changed, so that it only installs its own python if one is not already in the path. So cygwin users who have cygwin python installed at the time they first installed depot_tools, will end up using gyp with cygwin python. These cygwin generated vcproj files fail for several modules, notably nacl. I've corrected this in a somewhat hacky way, but the two now are basically identical. 2. Nacl currently makes extensive use of msvs_cygwin_shell: 0. This option in gyp was intended to allow direct access to cmd on windows. Most targets in chrome with actions/rules do not use this option. This option was intended as a backdoor for things like running setup_mount to get the hermetic cygwin initialized. Unfortunately, nacl's scons build made extensive use of scons's more flexible command line handling. In transitioning to gyp, several command lines where handled by using conditionals on platform, and using platform specific piping etc. msvs_cygwin_shell: 0, makes no attempt to setup cygwin or python in the path. As a result, at some point nacl folks added PYTHON_EXE, wrapper scripts, and other gyp variables to 'fix' the problem. These scripts didn't take into account the possibility that devenv.exe could be invoke with cygwin stuff in the path, and so fail when devenv is started from the command line. I've corrected these scripts so that they work in the presence of cygwin. This is, however, a stopgap. What really needs to happen is that all actions/rules in nacl's gyp files should NOT use msvs_cygwin_shell. This will mean adding some additional python wrapper scripts / changing the assumption in existing scripts that the build system is capable of handling piping. 3. A little while back we had a miscommunication about output directories. Nacl has started generating 32 and 64 bit output. A change went into nacl's common.gypi which causes output to go to Debug-Win32 / Debug-x64. Since none of chrome's infrastructure knows to clobber these directories, incremental builds can hide problems. This got fixed about a week ago. So all the output should be under Debug. So far so good on the command line build I started at the beginning of this email. I'll drop by and see if you're still hitting issues this afternoon. -BradN On Tue, Dec 1, 2009 at 9:39 AM, Brad Chen wrote: > [+ilewis] > > I'm happy to hear the Visual Studio GUI build is working; I think this was > the fix Brad Nelson submitted yesterday. I don't think we've tested a build > using a script such as you suggest. We're checking it out now. > > I apologize for the disruption. The diversity of ways people build on > Windows and Linux is challenging, and we have difficulty supporting kinds of > builds we don't know about. The Chrome Windows build looks greenish. It's > much easier for my team to support Windows/Linux build environments if they > are represented in the buildbots. If somebody has ideas for how this > specific issue can be better represented in the Chrome buildbots I'm very > interested. > > Brad > > On Tue, Dec 1, 2009 at 9:24 AM, Antony Sargent wrote: > >> I've tried a few combinations of deleting my Debug directory and running >> "gclient runhooks", and I *think* I've narrowed the problem down to the >> build failing if do a command-line build, but working ok if I build from >> within the Visual Studio GUI. The script I have which does the (now failing) >> command line build does: >> >> devenv.exe chrome.sln /Build Debug /Out C:\\tmp\\build.log /Project chrome >> >> This worked fine until quite recently. >> >> >> On Tue, Dec 1, 2009 at 12:18 AM, Peter Kasting wrote: >> >>> On Mon, Nov 30, 2009 at 10:01 PM, Antony Sargent >>> wrote: >>> I just updated to revision 33425, and a clean build (manually deleted Debug directory before opening .sln file) gives the following error in service_runtime_x86. I'm running Visual Studio 2008 on Vista x64. Anyone else seeing this, or know what might be the problem? >>> >>> >>> NaCl has had problem
[chromium-dev] Extension for context menu?
Hi chomium-dev, When could we add context menu items in an extension? I really which at least there would be something like FlashGot or DownloadThemAll for Chrome. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] webcore_bindings target builds slowly
DerivedSourcesAllInOne.cpp is the biggest bottleneck on Linux too. Even when running make with a high -j value, one would end up in the situation where one core is pegged for more than a minutes while all the others sit idle. On Tue, Dec 1, 2009 at 10:57 AM, Lei Zhang wrote: > DerivedSourcesAllInOne.cpp is the biggest bottleneck on Linux too. > Even when running make with a high -j value, one would end up in the > situation where one core is pegged for more than a minutes while all > the others sit idle. > > On Tue, Dec 1, 2009 at 9:32 AM, Jens Alfke wrote: >> On Mac* the WebCore Xcode project has a separate build target >> "webcore_bindings" that contains DerivedSourcesAllInOne.cpp and a >> handful of other files. This setup is really slowing down the build >> process on my Mac Pro, because DerivedSourcesAllInOne takes much >> longer to compile than any of the other sources in that target (since >> it #includes about 100 .cpp files), so there's a long period where one >> of the 8 cores is compiling that one file while the others are >> twiddling their thumbs. >> >> (I notice this especially because I've been working on V8 bindings >> stuff lately, so everything I touch tends to force that target to >> rebuild.) >> >> This could be improved either by >> a- merging this target in with the main WebCore target (didn't it use >> to be that way?) >> b- adding more files to this target to give the other cores something >> to do >> c- breaking up DerivedSourcesAllInOne into several pieces to compile >> simultaneously >> >> Anyone have any thoughts about this? (Option c seems attractively easy >> to do...) >> >> —Jens >> >> *maybe this applies to other platforms too, since the basic build >> structure comes from the shared .gyp file? >> >> -- >> Chromium Developers mailing list: chromium-dev@googlegroups.com >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev >> > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] webcore_bindings target builds slowly
On Mac* the WebCore Xcode project has a separate build target "webcore_bindings" that contains DerivedSourcesAllInOne.cpp and a handful of other files. This setup is really slowing down the build process on my Mac Pro, because DerivedSourcesAllInOne takes much longer to compile than any of the other sources in that target (since it #includes about 100 .cpp files), so there's a long period where one of the 8 cores is compiling that one file while the others are twiddling their thumbs. (I notice this especially because I've been working on V8 bindings stuff lately, so everything I touch tends to force that target to rebuild.) This could be improved either by a- merging this target in with the main WebCore target (didn't it use to be that way?) b- adding more files to this target to give the other cores something to do c- breaking up DerivedSourcesAllInOne into several pieces to compile simultaneously Anyone have any thoughts about this? (Option c seems attractively easy to do...) —Jens *maybe this applies to other platforms too, since the basic build structure comes from the shared .gyp file? -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on XP Perf (1), revision 33448
Automatically closing tree for "taskkill" on "XP Perf (1)" http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf%20%281%29/builds/1643 http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Perf%20%281%29 --=> Automatically closing tree for "taskkill" on "XP Perf (1)" <=-- Revision: 33445, 33446, 33447, 33448 Blame list: dglaz...@chromium.org,fin...@chromium.org,pinker...@chromium.org,senorbla...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] NaCl related build error
I've tried a few combinations of deleting my Debug directory and running "gclient runhooks", and I *think* I've narrowed the problem down to the build failing if do a command-line build, but working ok if I build from within the Visual Studio GUI. The script I have which does the (now failing) command line build does: devenv.exe chrome.sln /Build Debug /Out C:\\tmp\\build.log /Project chrome This worked fine until quite recently. On Tue, Dec 1, 2009 at 12:18 AM, Peter Kasting wrote: > On Mon, Nov 30, 2009 at 10:01 PM, Antony Sargent wrote: > >> I just updated to revision 33425, and a clean build (manually deleted >> Debug directory before opening .sln file) gives the following error in >> service_runtime_x86. I'm running Visual Studio 2008 on Vista x64. Anyone >> else seeing this, or know what might be the problem? > > > NaCl has had problems building with Cygwin for almost two weeks. I believe > Brad Nelson just fixed things, so try wiping out your Debug/ dir, > re-syncing, and rebuilding. (I haven't yet tested this myself.) > > PK > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] UI Jank Task Force Status Update
*UI Jank Task Force Status Update* The UI Jank Task Force is out to fix UI Jank and slowness in the browser. A list of open Jank bugs is here: http://code.google.com/ p/chromium/issues/list?q=label:Jank (feel free to take one!) *Updates* John - Bug fixing - "Last shutdown" file Lookup on startup to different thread - Looking at remaining Jank bugs this week Carlos - Sick, OOO last week - Pointer to an API to detect if memory is paged out. Still not sure it is possible given the API, but investigating further. - Ricardo's experiments indicate that backing stores may not be paged out after sleep? - AI: John & Glenn to follow up with Ricardo - Another contributor working on PGO, but hasn't been able to get it working either (VS2010 may be better than VS2005.) - AI: Carlos to file a ticket about linker limits (only 5 linkers spawned) - AI: John to run startup perf tests with PGO build. Chase - Tools work, perf tests, reference builds last week. Evan - No jank updates. Tony - Added reference builds for new tab tests. - Investigating thread contention for new tab creation. - Elliot changing how themes are stored on disk, should make theme startup faster (cram all files into one.) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Xcode, whitespace and you
We do now: 7433107 Add preference to Xcode to automatically add newline to end of file Cheers, Dave On Dec 1, 2009, at 5:29 AM, Thomas Van Lenten wrote: > Dave - do you have a radar for the trailing newline also? > > TVL > > > On Tue, Dec 1, 2009 at 12:39 AM, Dave MacLachlan > wrote: > > On Nov 30, 2009, at 4:57 PM, Mark Mentovai wrote: > > > > All with backend stuff, though. > > > > I'll poke and see. > > You may want to reference radar 7432370: Add preference to Xcode to > strip useless eol whitespace. > > Cheers, > Dave > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: >http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Fwd: [chromium-dev] Where buildbot outputs the intermediate builds?
repost from right account... -- Forwarded message -- Date: Tue, Dec 1, 2009 at 10:50 AM Subject: Re: [chromium-dev] Where buildbot outputs the intermediate builds? To: robj.pe...@gmail.com Cc: Chromium-dev On Tue, Dec 1, 2009 at 10:27 AM, Roberto wrote: > Are the buildbots archiving the intermediate builds before building > the final executable? > > If they do, where are they saving them? are they available to > download? > I don't believe we save all of them, some might get included in what is liked to off the waterfall. > If they don't, it would be pretty good if the "masters of buildbots" > could assist in this topic :) > > As we talked in this thread: > > > http://groups.google.com/group/chromium-dev/browse_thread/thread/301e4963629ce6bb/03e5d21c77d6f9a1#03e5d21c77d6f9a1 > > It would be quite useful in order to avoid the first big and time- > consuming build. > So the first issue is probably disk space it would take, especially for debug bits, we would quickly chew through a *lot* of disk space. I haven't looked, but how many platform end up with full paths on debug symbols? ie-would they even work? > I want to give a try to the possibility of incorporating to the first > check out the built libraries for each module. > If it works, the next point would be to modify gclient in order to > automatically checkout this built libraries as well. > > So we'd need to have built libraries for just about every possible revision as a checkout point? Even the build bots don't always do that as their cycling can result in a few cls being lumped together for a given spin. The other trick would be to make sure the process by which they get dropped on the local machine works for timestamps with different timezones to make sure it really doesn't rebuild things. The catch is if you have a local edit, and you last changed it before the sync would the built libraries have newer timestamps (because the bot happened to cycle in time), you'd actually want to make sure you get rebuilds for that case. So off the cuff, this sounds like it could be a win, but when weighted against the work it would take and how often it might not find said bits, I'm not so sure. The existing work on the webkit api so that could become a binary we use, is more limited, but seems like it might be a more attainable win. TVL > Thanks :) > > Roberto. > > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: >http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Where buildbot outputs the intermediate builds?
I had intention in archiving the intermediate build outputs in a shallow git repo for try server speedup but I have no intention in publishing this repo externally. I would recommend you to checkout the buildbot code and setup a local continuous build yourself. Instructions: http://dev.chromium.org/developers/testing/chromium-build-infrastructure/getting-the-buildbot-source Patches are welcome for the shallow git repo functionality. M-A On Tue, Dec 1, 2009 at 10:27 AM, Roberto wrote: > Are the buildbots archiving the intermediate builds before building > the final executable? > > If they do, where are they saving them? are they available to > download? > > If they don't, it would be pretty good if the "masters of buildbots" > could assist in this topic :) > > As we talked in this thread: > > > http://groups.google.com/group/chromium-dev/browse_thread/thread/301e4963629ce6bb/03e5d21c77d6f9a1#03e5d21c77d6f9a1 > > It would be quite useful in order to avoid the first big and time- > consuming build. > > I want to give a try to the possibility of incorporating to the first > check out the built libraries for each module. > If it works, the next point would be to modify gclient in order to > automatically checkout this built libraries as well. > > Thanks :) > > Roberto. > > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: >http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Never build chromium by Visual Studio 2008 + SP1
Thanks for the notice but we have good performance regression testing. Also, the official builds don't use /O2. Only the continuous build uses /O2. IIRC, VS2008 RTM cannot be used to build Chromium. M-A On Tue, Dec 1, 2009 at 4:54 AM, avcoder wrote: > Sorry: > > .I can only get about 34xx score if i built chromium > by VS2005, but I get 23xx score if I built with VS2008, the > performance difference is huge( 34xx vs 23xx) > > should be: > > .I can get about 34xx score if i built chromium > by VS2005, but I only get 23xx score if I built with VS2008, the > performance difference is huge( 34xx vs 23xx) > > On Dec 1, 5:49 pm, avcoder wrote: > > Dear: > > > > Never build chromium by Visual Studio 2008 + SP1, otherwise, you will > > get huge performance penalty > > ***Visual Studio 2008 C++ code slower than Visual Studio 2005*** > > > > Please check the following link: > http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/fb3203... > > > > "In Visual Studio 2008 SP1 (SP1 not RTM) there is a serious bug with / > > O2 optimization. One way this bug can be triggered is by upgrading a > > project from a previous version. Even though the project setting shows > > the release build is set to /O2, the build can be not optimized at > > all. To work around it you have to change the setting to no > > optimization, apply, and then change it back to /O2. The quick way to > > see if this is needed is to check whether the setting for optimization > > is in bold or regular - if's it's bold you're OK; if it's regular text > > you're not. > > > > This bug has been reported to Microsoft by many people over the past > > few months via the Connect feedback site but every case has been > > closed by them without doing anything and for completely invalid > > reasons." > > > > I benchmarked the latest chromium in release version with same > > benchmarker tool .I can only get about 34xx score if i built chromium > > by VS2005, but I get 23xx score if I built with VS2008, the > > performance difference is huge( 34xx vs 23xx) > > > > It seems that one of the following conclusions is true: > > 1) VS2008 + SP1 is broken on /O2 optimization > > 2) chromium gyp delivers bad configuration for VS2008(/O2 is ignored) > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: >http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Where buildbot outputs the intermediate builds?
Are the buildbots archiving the intermediate builds before building the final executable? If they do, where are they saving them? are they available to download? If they don't, it would be pretty good if the "masters of buildbots" could assist in this topic :) As we talked in this thread: http://groups.google.com/group/chromium-dev/browse_thread/thread/301e4963629ce6bb/03e5d21c77d6f9a1#03e5d21c77d6f9a1 It would be quite useful in order to avoid the first big and time- consuming build. I want to give a try to the possibility of incorporating to the first check out the built libraries for each module. If it works, the next point would be to modify gclient in order to automatically checkout this built libraries as well. Thanks :) Roberto. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Information about revisions
Dear chromiumers,
Relatively recently I stopped seeing information about revisions for
build bot graphs. If I open our debugger it reports something like:
Uncaught TypeError: Cannot call method 'slice' of undefined.
Line number it gives is incorrect. Most probably it should be actually line 50:
function received_data(data) {
var tbody = document.getElementById("tbody");
data.replace('\r', '');
var col_sums = [];
var rows = data.split('\n');
for (var i = 0; i < rows.length; ++i) {
var tr = document.createElement("TR");
var cols = rows[i].split(' ');
// cols[0] = page name
// cols[1] = (mean+/-standard deviation):
// cols[2...] = individual runs
// Require at least the page name and statistics.
if (cols.length < 2)
continue;
var page = cols[0];
var values = cols[1].split('+/-');
append_column(tr, page, col_sums, -1);
append_column(tr, values[0].slice(1), col_sums, 0); // HERE WE'RE FAILING
append_column(tr, values[1].slice(0,-2), col_sums, 1);
for (var j = 2; j < cols.length; ++j)
append_column(tr, cols[j], col_sums, j);
tbody.appendChild(tr);
}
It looks like data are returned in a wrong format. Chances are it is
a problem with DOM or Dromaeo benchmarks, but I cannot see rev info
for other build bots either (e.g. Page Cycler Moz), there is no
exception however.
Any ideas what goes on?
yours,
anton.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Webkit Linux (valgrind), revision 33441
Automatically closing tree for "compile" on "Webkit Linux (valgrind)" http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Linux%20%28valgrind%29/builds/7118 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Linux%20%28valgrind%29 --=> Automatically closing tree for "compile" on "Webkit Linux (valgrind)" <=-- Revision: 33441 Blame list: pfeld...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Never build chromium by Visual Studio 2008 + SP1
Sorry: .I can only get about 34xx score if i built chromium by VS2005, but I get 23xx score if I built with VS2008, the performance difference is huge( 34xx vs 23xx) should be: .I can get about 34xx score if i built chromium by VS2005, but I only get 23xx score if I built with VS2008, the performance difference is huge( 34xx vs 23xx) On Dec 1, 5:49 pm, avcoder wrote: > Dear: > > Never build chromium by Visual Studio 2008 + SP1, otherwise, you will > get huge performance penalty > ***Visual Studio 2008 C++ code slower than Visual Studio 2005*** > > Please check the following > link:http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/fb3203... > > "In Visual Studio 2008 SP1 (SP1 not RTM) there is a serious bug with / > O2 optimization. One way this bug can be triggered is by upgrading a > project from a previous version. Even though the project setting shows > the release build is set to /O2, the build can be not optimized at > all. To work around it you have to change the setting to no > optimization, apply, and then change it back to /O2. The quick way to > see if this is needed is to check whether the setting for optimization > is in bold or regular - if's it's bold you're OK; if it's regular text > you're not. > > This bug has been reported to Microsoft by many people over the past > few months via the Connect feedback site but every case has been > closed by them without doing anything and for completely invalid > reasons." > > I benchmarked the latest chromium in release version with same > benchmarker tool .I can only get about 34xx score if i built chromium > by VS2005, but I get 23xx score if I built with VS2008, the > performance difference is huge( 34xx vs 23xx) > > It seems that one of the following conclusions is true: > 1) VS2008 + SP1 is broken on /O2 optimization > 2) chromium gyp delivers bad configuration for VS2008(/O2 is ignored) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Never build chromium by Visual Studio 2008 + SP1
Dear: Never build chromium by Visual Studio 2008 + SP1, otherwise, you will get huge performance penalty ***Visual Studio 2008 C++ code slower than Visual Studio 2005*** Please check the following link: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/fb32033b-7bad-439b-a94c-943a17f0cbb2 "In Visual Studio 2008 SP1 (SP1 not RTM) there is a serious bug with / O2 optimization. One way this bug can be triggered is by upgrading a project from a previous version. Even though the project setting shows the release build is set to /O2, the build can be not optimized at all. To work around it you have to change the setting to no optimization, apply, and then change it back to /O2. The quick way to see if this is needed is to check whether the setting for optimization is in bold or regular - if's it's bold you're OK; if it's regular text you're not. This bug has been reported to Microsoft by many people over the past few months via the Connect feedback site but every case has been closed by them without doing anything and for completely invalid reasons." I benchmarked the latest chromium in release version with same benchmarker tool .I can only get about 34xx score if i built chromium by VS2005, but I get 23xx score if I built with VS2008, the performance difference is huge( 34xx vs 23xx) It seems that one of the following conclusions is true: 1) VS2008 + SP1 is broken on /O2 optimization 2) chromium gyp delivers bad configuration for VS2008(/O2 is ignored) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] NaCl related build error
On Mon, Nov 30, 2009 at 10:01 PM, Antony Sargent wrote: > I just updated to revision 33425, and a clean build (manually deleted Debug > directory before opening .sln file) gives the following error in > service_runtime_x86. I'm running Visual Studio 2008 on Vista x64. Anyone > else seeing this, or know what might be the problem? NaCl has had problems building with Cygwin for almost two weeks. I believe Brad Nelson just fixed things, so try wiping out your Debug/ dir, re-syncing, and rebuilding. (I haven't yet tested this myself.) PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Waiting for things in ResourceDispatcherHost
A cleaner more generalized solutions sounds excellent to me. Adapting consumers to that incrementally is a plus if you can do it. It might help the discussion if you could toss out a proposal for what you think might work. -Darin On Mon, Nov 30, 2009 at 1:59 PM, Paweł Hajdan Jr. wrote: > Currently we don't start the request in ResourceDispatcherHost until the > user script is ready (or not needed). UserScriptListener handles that. We > also wait for SafeBrowsing, Plugins, etc. We're going to wait for > PrivacyBlacklists. > > I was thinking about refactoring RDH so that it would be easy to pause > requests (or not start them) until something is ready. For some things we > can just pause requests (like SafeBrowsing), for some we can't even start a > request (like Privacy Blacklist, which can block sending the referrer, User > Agent, cookies, etc or just cancel the entire request). > > How would you recommend doing that? I think I wouldn't switch all existing > things to it immediately (it's a complex piece of code). I'd probably start > with UserScriptListener just to try it, and then Privacy Blacklists. What do > you think? > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
