[chromium-dev] Is it possible to customize CXXFLAGS and CFLAGS when generating make file or invoking make?
Hi, I'd like to compile chromium with some special CFLAGS/CXXFLAGS, how can I do? I'm using make build on 64bit Linux. Regards James Su --~--~-~--~~~---~--~~ 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: Is it possible to customize CXXFLAGS and CFLAGS when generating make file or invoking make?
On Tue, Sep 22, 2009 at 12:07 AM, James Su su...@chromium.org wrote:
I'd like to compile chromium with some special CFLAGS/CXXFLAGS, how can I
do? I'm using make build on 64bit Linux.
Yes, e.g. create ~/.gyp/include.gypi
{
'variables': {
'release_extra_cflags': '-g',
'debug_extra_cflags': '--fno-frobozz',
}
}
and then do gclient runhooks --force
--~--~-~--~~~---~--~~
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: Is it possible to customize CXXFLAGS and CFLAGS when generating make file or invoking make?
Thanks, I'll try.
James Su
2009/9/22 Dan Kegel d...@kegel.com
On Tue, Sep 22, 2009 at 12:07 AM, James Su su...@chromium.org wrote:
I'd like to compile chromium with some special CFLAGS/CXXFLAGS, how can
I
do? I'm using make build on 64bit Linux.
Yes, e.g. create ~/.gyp/include.gypi
{
'variables': {
'release_extra_cflags': '-g',
'debug_extra_cflags': '--fno-frobozz',
}
}
and then do gclient runhooks --force
--~--~-~--~~~---~--~~
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: Is it possible to customize CXXFLAGS and CFLAGS when generating make file or invoking make?
Looks like both CXXFLAGS=foo make and CXXFLAGS=foo hammer ignore CXXFLAGS. Is this by design? On Tue, Sep 22, 2009 at 12:07 AM, James Su su...@chromium.org wrote: Hi, I'd like to compile chromium with some special CFLAGS/CXXFLAGS, how can I do? I'm using make build on 64bit Linux. Regards James Su --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Xcode dependency analysis
I've confirmed this with Xcode 3.2; but my suspicion is it also happens with Xcode 3.1.x, just less frequently. In our build process, we run scripts in a few places to generate headers. Those steps are usually done via Actions on targets. We have listed all of the outputs generated so the tool chains can properly track the dependencies and figure out what needs to be rebuilt. It appears that Xcode has some bugs in this space. So it's possible to make changes to the input for one of these scripts (say a GRD files), and on your next build, the script will run to generate the new header, but Xcode appears to be checking the header before the script has run, so it doesn't always rebuild all the sources that include the headers. Most of the time, on the next build, the compiles will happen and your build will be back in a good state. So far my attempts to create a small test case have failed (the exact same setup, just will all the other sources removed, suddenly works). So if you are working on GRDs or localized XIB; and see odds issues with strings, you might have gotten bitten by this, a rebuild should fix it. Failing that, go for a clean build before spending too much time debugging just to make sure you aren't fighting the tool chain. TVL ps-this doesn't seem to be an issue with us missing dependencies for build order, this happens within a single target. I can get it to happen on a 4 core box, so it is not something that only shows with more parallelization. --~--~-~--~~~---~--~~ 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: Xcode dependency analysis
VS has the same kinds of problem when a project is reusing files generated inside it. The fix is usually splitting the project in two so that generated files by a rule/action aren't reused inside the same project. On Tue, Sep 22, 2009 at 8:30 AM, Thomas Van Lenten thoma...@chromium.org wrote: I've confirmed this with Xcode 3.2; but my suspicion is it also happens with Xcode 3.1.x, just less frequently. In our build process, we run scripts in a few places to generate headers. Those steps are usually done via Actions on targets. We have listed all of the outputs generated so the tool chains can properly track the dependencies and figure out what needs to be rebuilt. It appears that Xcode has some bugs in this space. So it's possible to make changes to the input for one of these scripts (say a GRD files), and on your next build, the script will run to generate the new header, but Xcode appears to be checking the header before the script has run, so it doesn't always rebuild all the sources that include the headers. Most of the time, on the next build, the compiles will happen and your build will be back in a good state. So far my attempts to create a small test case have failed (the exact same setup, just will all the other sources removed, suddenly works). So if you are working on GRDs or localized XIB; and see odds issues with strings, you might have gotten bitten by this, a rebuild should fix it. Failing that, go for a clean build before spending too much time debugging just to make sure you aren't fighting the tool chain. TVL ps-this doesn't seem to be an issue with us missing dependencies for build order, this happens within a single target. I can get it to happen on a 4 core box, so it is not something that only shows with more parallelization. --~--~-~--~~~---~--~~ 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: Is it possible to customize CXXFLAGS and CFLAGS when generating make file or invoking make?
For Make, I don't see any reason off the top of my head why that shouldn't work. For SCons, seems like no one's ever had the itch to add CXXFLAGS (and CCFLAGS) to the scons_import_variables list in build/common.gypi. LGTM if you're so inclined to add it. --SK On Tue, Sep 22, 2009 at 1:32 AM, Lei Zhang thes...@chromium.org wrote: Looks like both CXXFLAGS=foo make and CXXFLAGS=foo hammer ignore CXXFLAGS. Is this by design? On Tue, Sep 22, 2009 at 12:07 AM, James Su su...@chromium.org wrote: Hi, I'd like to compile chromium with some special CFLAGS/CXXFLAGS, how can I do? I'm using make build on 64bit Linux. Regards James Su --~--~-~--~~~---~--~~ 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: Is it possible to customize CXXFLAGS and CFLAGS when generating make file or invoking make?
I have a vague recollection of reviewing a change recently that I think in retrospect broke this for make. The trickiness is that each foo.o: foo.cc line has a target-local definition of CXXFLAGS, because otherwise any file mutating CXXFLAGS would mutate it for all rules. Without thinking through the consequences too hard, I think you could modify these lines in the generator: self.WriteLn($(OBJS): CFLAGS := $(CFLAGS_$(BUILDTYPE)) $(CFLAGS_C_$(BUILDTYPE)) $(DEFS_$(BUILDTYPE)) $(INCS_$(BUILDTYPE))) self.WriteLn($(OBJS): CXXFLAGS := $(CFLAGS_$(BUILDTYPE)) $(CFLAGS_CC_$(BUILDTYPE)) $(DEFS_$(BUILDTYPE)) $(INCS_$(BUILDTYPE))) to add in a reference $(CXXFLAGS) as well after the := , as that would reference the global CXXFLAGS while modifying only the local one. On Tue, Sep 22, 2009 at 1:32 AM, Lei Zhang thes...@chromium.org wrote: Looks like both CXXFLAGS=foo make and CXXFLAGS=foo hammer ignore CXXFLAGS. Is this by design? On Tue, Sep 22, 2009 at 12:07 AM, James Su su...@chromium.org wrote: Hi, I'd like to compile chromium with some special CFLAGS/CXXFLAGS, how can I do? I'm using make build on 64bit Linux. Regards James Su --~--~-~--~~~---~--~~ 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: Q about closing valgrind issues
I'd suspect an alignment / positioning bug for what you're seeing. Often rect fill algorithms have several paths with different loop unrolling tricks based on the size and position of the rect. I agree with Evan that it may be worth tracking this down a bit more. Even if it's not our bug, we need to find a way to avoid the memory stomping. I'm nervous about adding this to the upstream suppression list. I think that's OK to do for memory leaks, or for memory errors where it's been demonstrated that the result of the error is benign (like the UMRs in parts of Microsoft's STL implementation), but it doesn't seem like this fits into that case. Erik On Mon, Sep 21, 2009 at 1:15 PM, Avi Drissman a...@google.com wrote: I have no evidence to confirm/deny that. Even so it deserves an upstreaming. I'll look at it but why would it show up 1/30 times? Avi On Mon, Sep 21, 2009 at 4:07 PM, Evan Martin e...@chromium.org wrote: Could it possibly be related to passing a zero-sized rect in somewhere? On Mon, Sep 21, 2009 at 12:27 PM, Avi Drissman a...@google.com wrote: crbug.com/18189 crbug.com/18539 I got the first because it involved the status bubble; I got the second because I got the first. NSRectFill(). Deep down that ends up in sseCGSFill8by1, which looks like it sometimes scribbles off the end of some buffer. I have no idea what we could be doing wrong to cause it nor what we could be doing to affect it at all. I want to just dup one to the other and mark both as CANNOTFIXBADAPPLECODE^WWontFix. Any objections? Avi --~--~-~--~~~---~--~~ 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: user feedback one month in
I thought it was a well written and thoughtful piece, and the bookmarks star is not obvious for Firefox users as you have a load of bookmark options in the right button click menu, on tabs as well. Is this something that could be considered? It also makes sense if you are at the bottom of a page and want to bookmark it. I think he may not have noticed the CTRL-B for showing hiding the bookmarks bar. Nick On Sep 21, 3:43 am, Evan Martin e...@chromium.org wrote: It’s been a little over a month since I started using Chromium, the Open Source version of the Google Chrome Web browser. Since then, I’ve been using Chromium quite extensively. While the honeymoon isn’t over yet, I do have a better handle on what I like and dislike about Chromium and how it fits into my Web browsing and use of Web apps. http://scottnesbitt.net/ubuntublog/?p=511 Summary: Likes: speed, web compat(!), font rendering Unexpectedly ok with: lack of extensions Dislikes: - dropdown lists in wordpress admin panel don't behave well My response: any wordpress user here who can repro this? - CSS occasionally lost while browsing My response: I think I've seen this too, but I had been assuming it's site glitches. Does this ring any bells for anyone? - He's bookmarking by pasting urls into add page dialog found via the bookmark manager(!). Maybe he doesn't realize the star is the add bookmark button? My response: I'm no UI designer, but I wonder if it'd help to put the bookmark button star in some of the dialogs related to bookmarking? If you don't hover the star you'll never learn what it does; on the other hand, there are only seven buttons on the toolbar and I kind of don't have much pity for people who haven't looked at them. - splash page is annoying (estade removed it on Friday) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] git-try chromium + webkit
If you use (or consider using) Git, and also work on webkit (or any other 3rd party dependency actually) you may find the following valuable: The latest depot_tools (revision 26817+) makes it possible to use git-try to simultaneously test changes in both chromium and webkit. Simply type: git try -b BOT --webkit WEBKIT_BRANCH CHROMIUM_BRANCH A patch containing the diffs of src (against CHROMIUM_BRANCH) and src/third_party/WebKit (against WEBKIT_BRANCH) will be submitted to the try bots of your choice. The --webkit branch option is actually a syntax sugar to an even more powerful option: --sub_rep PATH BRANCH. This option can be used multiple times to specify a series of git sub-repositories to include in the try. Special thanks for Evan Martin and Marc-Antoine Ruel for helping me land this enhancement. -Yaar --~--~-~--~~~---~--~~ 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: git-try chromium + webkit
Thank you so much for doing this! :DG On Tue, Sep 22, 2009 at 9:39 AM, Yaar Schnitman y...@chromium.org wrote: If you use (or consider using) Git, and also work on webkit (or any other 3rd party dependency actually) you may find the following valuable: The latest depot_tools (revision 26817+) makes it possible to use git-try to simultaneously test changes in both chromium and webkit. Simply type: git try -b BOT --webkit WEBKIT_BRANCH CHROMIUM_BRANCH A patch containing the diffs of src (against CHROMIUM_BRANCH) and src/third_party/WebKit (against WEBKIT_BRANCH) will be submitted to the try bots of your choice. The --webkit branch option is actually a syntax sugar to an even more powerful option: --sub_rep PATH BRANCH. This option can be used multiple times to specify a series of git sub-repositories to include in the try. Special thanks for Evan Martin and Marc-Antoine Ruel for helping me land this enhancement. -Yaar --~--~-~--~~~---~--~~ 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: [linux] user feedback one month in
On Mon, Sep 21, 2009 at 4:52 AM, Elliot Glaysher (Chromium) e...@chromium.org wrote: On Sun, Sep 20, 2009 at 7:43 PM, Evan Martin e...@chromium.org wrote: - CSS occasionally lost while browsing My response: I think I've seen this too, but I had been assuming it's site glitches. Does this ring any bells for anyone? I see this at least twice a day on my home connection. A site will load except for the corresponding CSS. There doesn't appear to be a pattern to it. I see this on both Mac and Linux and I've heard complaints about it from Windows users in my family. In my personal case, it's usually coupled with pages that doesn't load (The webpage at ... might be temporarily down.) with an: Error 2 (net::ERR_FAILED): Unknown error. Reloading usually solves the issue, but it still seems like my running version of Chromium can get into a state where I either get garbled pages (lack of CSS) or pages that aren't available pretty frequently -- even though I'm accessing pretty major sites like http://news.com/ or http://jp.dk/ that I (almost) never have trouble accessing from other browsers. Does anyone know of a bug (http://crbug.com/) that track this issue? Cheers, Kasper -- Elliot --~--~-~--~~~---~--~~ 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: Xcode dependency analysis
I'm not sure I understand what you're saying. I assume you're aware that script phases in XCode list explicit dependencies. I think I'd have an easier time parsing your paragraph with specific examples. -eric On Tue, Sep 22, 2009 at 5:30 AM, Thomas Van Lenten thoma...@chromium.org wrote: I've confirmed this with Xcode 3.2; but my suspicion is it also happens with Xcode 3.1.x, just less frequently. In our build process, we run scripts in a few places to generate headers. Those steps are usually done via Actions on targets. We have listed all of the outputs generated so the tool chains can properly track the dependencies and figure out what needs to be rebuilt. It appears that Xcode has some bugs in this space. So it's possible to make changes to the input for one of these scripts (say a GRD files), and on your next build, the script will run to generate the new header, but Xcode appears to be checking the header before the script has run, so it doesn't always rebuild all the sources that include the headers. Most of the time, on the next build, the compiles will happen and your build will be back in a good state. So far my attempts to create a small test case have failed (the exact same setup, just will all the other sources removed, suddenly works). So if you are working on GRDs or localized XIB; and see odds issues with strings, you might have gotten bitten by this, a rebuild should fix it. Failing that, go for a clean build before spending too much time debugging just to make sure you aren't fighting the tool chain. TVL ps-this doesn't seem to be an issue with us missing dependencies for build order, this happens within a single target. I can get it to happen on a 4 core box, so it is not something that only shows with more parallelization. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [LTTF] Layout Tests Task Force
Hello, The Chromium team will be putting a lot of focus over the next few months on WebKit layout tests. In fact, we've created a Layout Tests Task Force, and anyone is welcome to contribute. As you know, layout tests are used to check the correctness of the renderer. Existing documentation on how to set up and run the tests is here: http://sites.google.com/a/chromium.org/dev/developers/testing/webkit-layout-tests . We've also set up a page which describes how the Task Force operates. In a nutshell, there are two exciting roles that anyone is free to choose from: Finders, and Fixers. http://sites.google.com/a/chromium.org/dev/developers/testing/webkit-layout-tests/task-force There's no shortage of layout tests to tackle, so go for it! We'll try to set up something to help us visualize our progress over time better. --~--~-~--~~~---~--~~ 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: [Green Tree] Week 1
Do we have anything running which monitors disk free space? It seems like in a couple of cases over the last few months getting email alerts when a bot's disk is 90% full might have helped alert Sheriffs/Troopers to a problem earlier and possibly prevent a tree closure. On Mon, Sep 21, 2009 at 10:31 AM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Sep 21, 2009 at 8:25 AM, Nicolas Sylvain nsylv...@chromium.orgwrote: Hi chromium-dev, A small group of us joined forces to create a Green Tree task force. The goal of this task force is to make sure the tree stays green most of the time. The 2 main pain points that we are attacking at this time are reducing the buildbot cycle time, to catch errors earlier, and getting rid of the flakiness, to make sure the tree does not turn red for no reason. I'll be prepending [Green Tree] to the emails I send related to the task force. You can also follow the progress and our tasks there: http://code.google.com/p/chromium/issues/list?q=label:GreenTreeTaskForce For those interested, these are the highlights of the last week: - Make sure all the tasks have bugs associated with them (pamg) - Make sure VMWare Tools is installed on all the slaves (bev / nsylvain) - Disable all services that we don't need on the slaves (bev) - Split the windows chromium tests in 3 slaves (maruel) - Change the gatekeeper to close the tree on more failures (maruel) - Change LKGR to care about more tests, and make it cycle faster (maruel) - Write a status page to see the cycle speed on the slaves (nsylvain) - Make sure we build only what we need on Mac (thomasvl) - Add more try bots (linux views, valgrind) (maruel) - Refactor Linux Valgrind buildbots into builder/testers. (mmoss) - Create a dashboard to see the slowest tests (phajdan) - Speed up the transfer of builds between builders/testers by reducing the compression (mmoss) I'm sure I forgot some, feel free to append to this list. Despite our efforts, this was one of the worse week we've seen in a long time in term of tree closure. This was caused by 5 main events: - Buildbot maintenance went wrong. By changing a mounted drive on the buildbot master, the mount table got corrupted, and we had to reboot the main server. We started the maintenance at 7:30AM (pacific) and we got the buildbot back online shortly after 10AM. It had to cycle a little, so it was closed for almost 3 hours - A webkit merge left some failures in the tree. And it looks like everyone left without fixing it, so it was closed overnight. We fixed it in the morning, but before reopening we let another webkit merge go by, and it also broke the tree, requiring a change on webkit.org to fix the reliability tests (IIRC). Total closure time: 20 hours. The more try bots we get, the better this will get. At the very least, when we check in something that upsets bots covered by try bots, we can always roll back out and triage without the tree closed. Maybe we should have one try bot for each different type of build bot? Btw, in case anyone is wondering what makes WebKit gardening special: WebKit is a freight train that we can't stop. And so, if we get behind by even a day, it has a serious impact on Chromium developers' ability to do a lot of stuff (especially 2 sided patches). I'm not trying to condone the 20 hour closure (I don't know the details), but if we can't figure out what's wrong quickly (when it breaks our stuff) we can get into a pretty bad situation pretty quickly. - A bad gclient change got checked in. Some machines stopped running runhooks and some bots got confused. The damage seems to have been limited. - A second bad gclient change got checked in. This time causing all the bots to throw away their checkouts. Almost each slaves had to do a full checkout (which takes an hour or so), and some of them ran out of disk space, so we had to manually fix them. The tree was closed for another couple of hours. - A bad DEPS file got checked in. Causing again a bunch of slaves to throw away their checkout. It was closed for another hour or two. Possibly crazy idea: Is there any way we can have a bot that only updates itself that all the other bots block on? Assuming that one bot syncing the world is faster than all the bots saving the world, it would save time. It seems like in the normal case, this will go quite quickly and not block things for long. But, when something's wrong with gclient, DEPS, etc it'll take a long time. Sheriffs could then close the tree and stop that bot's build before any of the other bots pick it up. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [LTTF] Goals for the Layout Tests Task Force
Hello, As mentioned previously, a Layout Tests Task Force has been created to tackle the noble problem of fixing all of the WebKit layout tests that Chromium is currently failing. (Documentation on the task force is here: http://sites.google.com/a/chromium.org/dev/developers/testing/webkit-layout-tests/task-force ) We have also assembled a set of goals for the next three months: http://sites.google.com/a/chromium.org/dev/developers/testing/webkit-layout-tests/goals They are pasted here for convenience: - Fix all Windows layout tests: make test_expectations.txt only contain items that we will never fix, features we have not yet implemented, or bugs less than one week old that are a result of a recent WebKit merge. - All LTTF bugs that we fix are fixed across all three platforms (Win, Mac, Linux), unless they depend on features not yet implemented. - Fix any crashing layout tests within a week of occurrence. - Work with the green tree task force to eliminate flakiness of layout tests. - Set up a public dashboard which tracks the number of failing layout tests over time on the Chromium site. Feedback is more than welcome! --~--~-~--~~~---~--~~ 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: [Green Tree] Week 1
On Mon, Sep 21, 2009 at 10:53 AM, Antony Sargent asarg...@chromium.orgwrote: Do we have anything running which monitors disk free space? It seems like in a couple of cases over the last few months getting email alerts when a bot's disk is 90% full might have helped alert Sheriffs/Troopers to a problem earlier and possibly prevent a tree closure. At this point the problem is that the build got bigger, and we can't fit 2 checkouts at the same time on the same machine. We are currently slowly replacing all the old 30GB VM with new one that has 70GB. Eventually we should try to implement some alert mechanism. Nicolas On Mon, Sep 21, 2009 at 10:31 AM, Jeremy Orlow jor...@chromium.orgwrote: On Mon, Sep 21, 2009 at 8:25 AM, Nicolas Sylvain nsylv...@chromium.orgwrote: Hi chromium-dev, A small group of us joined forces to create a Green Tree task force. The goal of this task force is to make sure the tree stays green most of the time. The 2 main pain points that we are attacking at this time are reducing the buildbot cycle time, to catch errors earlier, and getting rid of the flakiness, to make sure the tree does not turn red for no reason. I'll be prepending [Green Tree] to the emails I send related to the task force. You can also follow the progress and our tasks there: http://code.google.com/p/chromium/issues/list?q=label:GreenTreeTaskForce For those interested, these are the highlights of the last week: - Make sure all the tasks have bugs associated with them (pamg) - Make sure VMWare Tools is installed on all the slaves (bev / nsylvain) - Disable all services that we don't need on the slaves (bev) - Split the windows chromium tests in 3 slaves (maruel) - Change the gatekeeper to close the tree on more failures (maruel) - Change LKGR to care about more tests, and make it cycle faster (maruel) - Write a status page to see the cycle speed on the slaves (nsylvain) - Make sure we build only what we need on Mac (thomasvl) - Add more try bots (linux views, valgrind) (maruel) - Refactor Linux Valgrind buildbots into builder/testers. (mmoss) - Create a dashboard to see the slowest tests (phajdan) - Speed up the transfer of builds between builders/testers by reducing the compression (mmoss) I'm sure I forgot some, feel free to append to this list. Despite our efforts, this was one of the worse week we've seen in a long time in term of tree closure. This was caused by 5 main events: - Buildbot maintenance went wrong. By changing a mounted drive on the buildbot master, the mount table got corrupted, and we had to reboot the main server. We started the maintenance at 7:30AM (pacific) and we got the buildbot back online shortly after 10AM. It had to cycle a little, so it was closed for almost 3 hours - A webkit merge left some failures in the tree. And it looks like everyone left without fixing it, so it was closed overnight. We fixed it in the morning, but before reopening we let another webkit merge go by, and it also broke the tree, requiring a change on webkit.org to fix the reliability tests (IIRC). Total closure time: 20 hours. The more try bots we get, the better this will get. At the very least, when we check in something that upsets bots covered by try bots, we can always roll back out and triage without the tree closed. Maybe we should have one try bot for each different type of build bot? Btw, in case anyone is wondering what makes WebKit gardening special: WebKit is a freight train that we can't stop. And so, if we get behind by even a day, it has a serious impact on Chromium developers' ability to do a lot of stuff (especially 2 sided patches). I'm not trying to condone the 20 hour closure (I don't know the details), but if we can't figure out what's wrong quickly (when it breaks our stuff) we can get into a pretty bad situation pretty quickly. - A bad gclient change got checked in. Some machines stopped running runhooks and some bots got confused. The damage seems to have been limited. - A second bad gclient change got checked in. This time causing all the bots to throw away their checkouts. Almost each slaves had to do a full checkout (which takes an hour or so), and some of them ran out of disk space, so we had to manually fix them. The tree was closed for another couple of hours. - A bad DEPS file got checked in. Causing again a bunch of slaves to throw away their checkout. It was closed for another hour or two. Possibly crazy idea: Is there any way we can have a bot that only updates itself that all the other bots block on? Assuming that one bot syncing the world is faster than all the bots saving the world, it would save time. It seems like in the normal case, this will go quite quickly and not block things for long. But, when something's wrong with gclient, DEPS, etc it'll take a long time. Sheriffs could then close the tree and stop that bot's build before any of the other
[chromium-dev] Re: Chromium isn't shutting down cleanly
On Tue, Sep 22, 2009 at 10:39 AM, Daniel Cowx daniel.c...@gmail.com wrote: Can someone please provide a bit of insight into how to solve the following problem: 1. Open Chromium Options Show saved passwords 2. Click the Remove All button Now, *before* you click Yes or No, close the main browser window (e.g. by clicking the X in the upper right corner). When you do this, all windows disappear, but the main browser process remains running. It looks like this is due to a nested invocation of MessageLoop::Run() (via chrome\browser\views\confirm_message_box_dialog.cc) and the fact that Quit is only exiting the most recent invocation. How can we cleanly quit the application in this case? Explicitly CCing a couple people who know nested message loops best. PK --~--~-~--~~~---~--~~ 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: Q about closing valgrind issues
If this is caught in the unit tests ~1/30 times, then it's happening despite the window positionings and view positionings being the same. There's multiple layers of indirection in there (two context types, four libraries) all totally closed source. Tracking it down feels like it would take way too much effort and I'm swamped. If you have some spare time... Avi On Tue, Sep 22, 2009 at 11:56 AM, Erik Kay erik...@chromium.org wrote: I'd suspect an alignment / positioning bug for what you're seeing. Often rect fill algorithms have several paths with different loop unrolling tricks based on the size and position of the rect. I agree with Evan that it may be worth tracking this down a bit more. Even if it's not our bug, we need to find a way to avoid the memory stomping. I'm nervous about adding this to the upstream suppression list. I think that's OK to do for memory leaks, or for memory errors where it's been demonstrated that the result of the error is benign (like the UMRs in parts of Microsoft's STL implementation), but it doesn't seem like this fits into that case. Erik On Mon, Sep 21, 2009 at 1:15 PM, Avi Drissman a...@google.com wrote: I have no evidence to confirm/deny that. Even so it deserves an upstreaming. I'll look at it but why would it show up 1/30 times? Avi On Mon, Sep 21, 2009 at 4:07 PM, Evan Martin e...@chromium.org wrote: Could it possibly be related to passing a zero-sized rect in somewhere? On Mon, Sep 21, 2009 at 12:27 PM, Avi Drissman a...@google.com wrote: crbug.com/18189 crbug.com/18539 I got the first because it involved the status bubble; I got the second because I got the first. NSRectFill(). Deep down that ends up in sseCGSFill8by1, which looks like it sometimes scribbles off the end of some buffer. I have no idea what we could be doing wrong to cause it nor what we could be doing to affect it at all. I want to just dup one to the other and mark both as CANNOTFIXBADAPPLECODE^WWontFix. Any objections? Avi --~--~-~--~~~---~--~~ 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: [LTTF] Goals for the Layout Tests Task Force
On Tue, Sep 22, 2009 at 10:26 AM, Jeffrey Chang jeffr...@google.com wrote: - Fix all Windows layout tests: make test_expectations.txt only contain items that we will never fix, features we have not yet implemented, or bugs less than one week old that are a result of a recent WebKit merge. - Set up a public dashboard which tracks the number of failing layout tests over time on the Chromium site. How do you intend to track these numbers? Right now we have no way to distinguish between failures that need fixing versus failures due to unimplemented features. One way would be to use DEFER again. All the support is still there, and the initial code for the tracking dashboard exposes it. It would mostly just work. I propose that we bring back to defer, but use it *only* for tests that fail due to unimplemented features. Ojan --~--~-~--~~~---~--~~ 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: [LTTF] Goals for the Layout Tests Task Force
Yep. Dirk was the one to suggest bringing it back. I didn't put this in the documentation, but only because I wasn't yet sure whether we'll track them by bug milestone or explicitly using the tag. :DG On Tue, Sep 22, 2009 at 11:33 AM, Ojan Vafai o...@chromium.org wrote: On Tue, Sep 22, 2009 at 10:26 AM, Jeffrey Chang jeffr...@google.com wrote: Fix all Windows layout tests: make test_expectations.txt only contain items that we will never fix, features we have not yet implemented, or bugs less than one week old that are a result of a recent WebKit merge. Set up a public dashboard which tracks the number of failing layout tests over time on the Chromium site. How do you intend to track these numbers? Right now we have no way to distinguish between failures that need fixing versus failures due to unimplemented features. One way would be to use DEFER again. All the support is still there, and the initial code for the tracking dashboard exposes it. It would mostly just work. I propose that we bring back to defer, but use it *only* for tests that fail due to unimplemented features. Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] this webpage is not available
After hitting this message about twenty times over the last couple days, and getting pinged by various people about it, I went looking for a corresponding bug report. The closest match seems to be http://crbug.com/22623 so I updated that and marked it high priority. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Don't edit webcore.gyp javascriptcore.gyp
I'm in the middle of a 2-step commit, so PLEASE DONT EDIT these files until the commit is through. These two gyp files have been upstreamed to webkit.org and are about to be removed from the chromium tree. src/webkit/webcore.gyp moved to src/third_party/WebKit/WebCore/WebCore.gyp/WebCore.gyp(Yes, WebCore.gyp twice) src/webkit/javascriptcore.gyp moved to src/third_party/WebKit/JavaScriptCore/JavaScriptCore.gyp/JavaScriptCore.gyp I will really remove them and make webkit.gyp depend on the upstream files once we catch up with the relevant webkit revision. I'm sorry for the temporary inconvenience or delays this may cause. -Yaar p.s. You are welcome to start editing upstream WebCore.gyp JavaScriptCore.gyp of course. --~--~-~--~~~---~--~~ 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: Chromium isn't shutting down cleanly
In the case you indicated, the main thread call stack probably includes the invocation of the nested message loop. I think this nesting is usally required because we enter a special windows message loop that handles native windows (dialog boxes). We use some very fancy footwork to cause this native message loop to actually provide time slices to service the Chrome task queue etc..As a result, until that native window terminates (user clicks OK) there is no way for the basic browser process to terminate (cleanly) as the main UI thread is still running. When *finally* you do hit the OK button on the native dialog, then the dialog will terminate, and (if you have closed the main browser window) the main UI thread can unwind and the browser process can really terminate. Typically a Quit() call to the MessageLoop sets the state to indicate that the (current) loop should exit soon (when next it seems idle?). ...at least that was the way it was supposed to play out... There is a chance that someone put in a nested message loop from Chrome for a Chrome dialog. In that case, the multitude of Quit() calls at various nesting depths could be (incorrectly) aggregated by a nested Chrome message loop. Historically we've seen problems like that... but I thought we had handled such (and strongly discouraged the use of nested message loops). Looking at the UI, I can see the Options dialog; the Show-All dialog; and the Are You Sure dialog. It would be most desirable if all of those dialogs were native, and none involved a nested Chrome message loop. If there was a nested Chrome message loop, extra care would be needed to be sure the extra Quit() calls were not aggregated (losing the extra one). So that's something to look at. If the problem is as mentioned, we'd need to either stop using a nested message loop, or be a little more careful in the nested message loop about losing the extra quit message. A more traditional approach is to make the last Are You Sure dialog application-modal, so that you can't terminate the browser while it is displayed/pending (but I think we try as much as possible to avoid modal dialogs). At some point I recall looking at more targetted Quit() messages, that terminate only a given MessageLoop, and also looking at counting the number of Quit() invocations, so that the excess at a nested level propogated upwards. I think it was decided that such situations would better be avoided. (The count of the number of Quit() messages can wreak havoc if a high level Quit() causes a nested loop to terminate instead :-/ ). Jim p.s., Please cc me on the CL for any fix you decided on. On Tue, Sep 22, 2009 at 10:47 AM, Peter Kasting pkast...@google.com wrote: On Tue, Sep 22, 2009 at 10:39 AM, Daniel Cowx daniel.c...@gmail.comwrote: Can someone please provide a bit of insight into how to solve the following problem: 1. Open Chromium Options Show saved passwords 2. Click the Remove All button Now, *before* you click Yes or No, close the main browser window (e.g. by clicking the X in the upper right corner). When you do this, all windows disappear, but the main browser process remains running. It looks like this is due to a nested invocation of MessageLoop::Run() (via chrome\browser\views\confirm_message_box_dialog.cc) and the fact that Quit is only exiting the most recent invocation. How can we cleanly quit the application in this case? Explicitly CCing a couple people who know nested message loops best. PK --~--~-~--~~~---~--~~ 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: this webpage is not available
When you see this error page, it is helpful to report the error code. Please toggle the widget to reveal the error code.-Darin On Tue, Sep 22, 2009 at 11:39 AM, Dan Kegel d...@kegel.com wrote: After hitting this message about twenty times over the last couple days, and getting pinged by various people about it, I went looking for a corresponding bug report. The closest match seems to be http://crbug.com/22623 so I updated that and marked it high priority. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] When disabling a test, please assign to whoever wrote it
It only takes a few moments to figure out this information, and ensures that the bug lands on the right person's desk. http://src.chromium.org/viewvc/chrome/trunk/src/ can show who wrote the initial test For commits before we moved to the open source repository, look at http://chrome-corpsvn.mtv/viewvc/trunk/?root=chrome (internal only) Thanks --~--~-~--~~~---~--~~ 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: [LTTF] Goals for the Layout Tests Task Force
Yes, exactly. I'm working on some additional reports and dashboards that will allow us to track the funnel of finds/fixes better as well. -- Dirk On Tue, Sep 22, 2009 at 11:38 AM, Dimitri Glazkov dglaz...@chromium.org wrote: Yep. Dirk was the one to suggest bringing it back. I didn't put this in the documentation, but only because I wasn't yet sure whether we'll track them by bug milestone or explicitly using the tag. :DG On Tue, Sep 22, 2009 at 11:33 AM, Ojan Vafai o...@chromium.org wrote: On Tue, Sep 22, 2009 at 10:26 AM, Jeffrey Chang jeffr...@google.com wrote: Fix all Windows layout tests: make test_expectations.txt only contain items that we will never fix, features we have not yet implemented, or bugs less than one week old that are a result of a recent WebKit merge. Set up a public dashboard which tracks the number of failing layout tests over time on the Chromium site. How do you intend to track these numbers? Right now we have no way to distinguish between failures that need fixing versus failures due to unimplemented features. One way would be to use DEFER again. All the support is still there, and the initial code for the tracking dashboard exposes it. It would mostly just work. I propose that we bring back to defer, but use it *only* for tests that fail due to unimplemented features. Ojan --~--~-~--~~~---~--~~ 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: When disabling a test, please assign to whoever wrote it
Seriously. In a project as big as Chrome, tests are *critical* and a disabled test can hurt a team within just a few days. This has happened to me a few times and it is terrifying to find out a test that you think was proving you are working had actually been disabled. Disabling bad tests is super important, and I'm not arguing against that. Just make sure that someone knows that it was done who can take action on it. - a On Tue, Sep 22, 2009 at 12:40 PM, John Abd-El-Malek j...@chromium.org wrote: It only takes a few moments to figure out this information, and ensures that the bug lands on the right person's desk. http://src.chromium.org/viewvc/chrome/trunk/src/ can show who wrote the initial test For commits before we moved to the open source repository, look at http://chrome-corpsvn.mtv/viewvc/trunk/?root=chrome (internal only) Thanks --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [LTTF] Status updates
Hello, Are you on the Layout Tests Task Force and wondering what your fellow taskforcers have been up to? Are you interested in joining the task force and want to see what everyone else has been working on? In the spirit of transparency, we're going to try collecting and sending out weekly status updates on what each member of the LTTF is doing. http://tinyurl.com/LTTFstatus I will email at the beginning of each week to remind people, and again later in the week to encourage people to take a look. Feel free to add yourself to the list if you join the task force! As always, I'd love to hear feedback, so if you think this is useless, or you think this is great, or you prefer email instead of spreadsheet, biweekly instead of weekly, etc., feel free to reply to me individually or publicly. Jeff --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] V8 object-graph-tracing utilities?
Are there any utilities that can be used to see which native (DOM) objects are being referenced by JavaScript objects, and to follow references between JS objects to understand what's keeping an object from being GCd? (I'm working on reducing Chrome memory usage. One thing I've discovered is that WebCore::DOMWindow objects (and all their associated object trees) are sometimes being left behind. JavaScript seems to be implicated, as the problem goes away if I disable JS. So something in V8 seems to be holding onto references to DOMWindows, and I'd like to find out what it is.) Thanks! —Jens --~--~-~--~~~---~--~~ 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: V8 object-graph-tracing utilities?
I'm working on showing JS objects retainers. But this only works for objects that live inside V8's heap. I'm not considering links between JS wrappers and C++ objects. I know Vitaly (cc'ed) wanted to do something about such cycles. On Wed, Sep 23, 2009 at 01:47, Jens Alfke s...@google.com wrote: Are there any utilities that can be used to see which native (DOM) objects are being referenced by JavaScript objects, and to follow references between JS objects to understand what's keeping an object from being GCd? (I'm working on reducing Chrome memory usage. One thing I've discovered is that WebCore::DOMWindow objects (and all their associated object trees) are sometimes being left behind. JavaScript seems to be implicated, as the problem goes away if I disable JS. So something in V8 seems to be holding onto references to DOMWindows, and I'd like to find out what it is.) Thanks! —Jens --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] debugging the browser started by UI tests
What's the best way to attach the debugger to a browser started by a UI test? How about doing that only in case of a crash? I'm looking for solution both for Windows and Linux, so if you have good techniques, it'd be really nice. I can even document them on the wiki, but currently I'm using LOG statements when debugging the browser (I know it's not the optimal and kind of sucks, but I couldn't find a good way to attach the debugger). --~--~-~--~~~---~--~~ 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: V8 object-graph-tracing utilities?
On Sep 22, 2009, at 2:54 PM, Mikhail Naganov wrote: I'm working on showing JS objects retainers. But this only works for objects that live inside V8's heap. That would still be useful — I'd love to be able to look at all the 'Window' objects in the heap and what ref chain is keeping them alive. Please let me know if there's something experimental I can try out. Thanks! —Jens --~--~-~--~~~---~--~~ 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: V8 object-graph-tracing utilities?
Because we have C++ and JS wrappers, and there may be references known to the C++ side not known to the JS side, we have to do an object grouping before we can call GC. This grouping takes all wrappers and groups them by their root; and then they are collected together. This happens in V8GCController::gcPrologue(). So you might fint that an interesting place to look. Mike On Tue, Sep 22, 2009 at 3:21 PM, Jens Alfke s...@google.com wrote: On Sep 22, 2009, at 2:54 PM, Mikhail Naganov wrote: I'm working on showing JS objects retainers. But this only works for objects that live inside V8's heap. That would still be useful — I'd love to be able to look at all the 'Window' objects in the heap and what ref chain is keeping them alive. Please let me know if there's something experimental I can try out. Thanks! —Jens --~--~-~--~~~---~--~~ 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: debugging the browser started by UI tests
On Linux and mac, if you set the BROWSER_WRAPPER environment variable, it'll run that as a prefix of chrome. E.g., BROWSER_WRAPPER=xterm -e gdb --args should open a new xterm with gdb for each browser window. On Tue, Sep 22, 2009 at 3:00 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: What's the best way to attach the debugger to a browser started by a UI test? How about doing that only in case of a crash? I'm looking for solution both for Windows and Linux, so if you have good techniques, it'd be really nice. I can even document them on the wiki, but currently I'm using LOG statements when debugging the browser (I know it's not the optimal and kind of sucks, but I couldn't find a good way to attach the debugger). --~--~-~--~~~---~--~~ 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: debugging the browser started by UI tests
If you uncomment WAIT_FOR_DEBUGGER_ON_OPEN on ui_test you'll be prompted. We really need to convert this into a comment line option. -Scott On Tue, Sep 22, 2009 at 3:00 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: What's the best way to attach the debugger to a browser started by a UI test? How about doing that only in case of a crash? I'm looking for solution both for Windows and Linux, so if you have good techniques, it'd be really nice. I can even document them on the wiki, but currently I'm using LOG statements when debugging the browser (I know it's not the optimal and kind of sucks, but I couldn't find a good way to attach the debugger). --~--~-~--~~~---~--~~ 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: debugging the browser started by UI tests
Both of these should go to the ui tests section of the debugging wiki, which is where I turned in attempting to answer Pawel's question: http://code.google.com/p/chromium/wiki/LinuxDebugging#UI_tests On Tue, Sep 22, 2009 at 4:03 PM, Scott Violet s...@chromium.org wrote: If you uncomment WAIT_FOR_DEBUGGER_ON_OPEN on ui_test you'll be prompted. We really need to convert this into a comment line option. -Scott On Tue, Sep 22, 2009 at 3:00 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: What's the best way to attach the debugger to a browser started by a UI test? How about doing that only in case of a crash? I'm looking for solution both for Windows and Linux, so if you have good techniques, it'd be really nice. I can even document them on the wiki, but currently I'm using LOG statements when debugging the browser (I know it's not the optimal and kind of sucks, but I couldn't find a good way to attach the debugger). --~--~-~--~~~---~--~~ 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: debugging the browser started by UI tests
WAIT_FOR_DEBUGGER_ON_OPEN predates the Linux port. It may work on Linux, I just haven't tried it. -Scott On Tue, Sep 22, 2009 at 4:06 PM, Evan Martin e...@chromium.org wrote: Both of these should go to the ui tests section of the debugging wiki, which is where I turned in attempting to answer Pawel's question: http://code.google.com/p/chromium/wiki/LinuxDebugging#UI_tests On Tue, Sep 22, 2009 at 4:03 PM, Scott Violet s...@chromium.org wrote: If you uncomment WAIT_FOR_DEBUGGER_ON_OPEN on ui_test you'll be prompted. We really need to convert this into a comment line option. -Scott On Tue, Sep 22, 2009 at 3:00 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: What's the best way to attach the debugger to a browser started by a UI test? How about doing that only in case of a crash? I'm looking for solution both for Windows and Linux, so if you have good techniques, it'd be really nice. I can even document them on the wiki, but currently I'm using LOG statements when debugging the browser (I know it's not the optimal and kind of sucks, but I couldn't find a good way to attach the debugger). --~--~-~--~~~---~--~~ 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: debugging the browser started by UI tests
Agreed, we should have a --browser-startup-dialog that's added to BrowserMain. ui_tests can then pass it and --renderer-startup-dialog, plugin-startup-dialog, in-process-plugins, --single-process along if they're specified. On Tue, Sep 22, 2009 at 4:03 PM, Scott Violet s...@chromium.org wrote: If you uncomment WAIT_FOR_DEBUGGER_ON_OPEN on ui_test you'll be prompted. We really need to convert this into a comment line option. -Scott On Tue, Sep 22, 2009 at 3:00 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: What's the best way to attach the debugger to a browser started by a UI test? How about doing that only in case of a crash? I'm looking for solution both for Windows and Linux, so if you have good techniques, it'd be really nice. I can even document them on the wiki, but currently I'm using LOG statements when debugging the browser (I know it's not the optimal and kind of sucks, but I couldn't find a good way to attach the debugger). --~--~-~--~~~---~--~~ 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: debugging the browser started by UI tests
What's the difference between WAIT_FOR_DEBUGGER_ON_OPEN and --wait-for-debugger / wait-for-debugger-children for renderers? On Tue, Sep 22, 2009 at 4:03 PM, Scott Violet s...@chromium.org wrote: If you uncomment WAIT_FOR_DEBUGGER_ON_OPEN on ui_test you'll be prompted. We really need to convert this into a comment line option. -Scott On Tue, Sep 22, 2009 at 3:00 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: What's the best way to attach the debugger to a browser started by a UI test? How about doing that only in case of a crash? I'm looking for solution both for Windows and Linux, so if you have good techniques, it'd be really nice. I can even document them on the wiki, but currently I'm using LOG statements when debugging the browser (I know it's not the optimal and kind of sucks, but I couldn't find a good way to attach the debugger). --~--~-~--~~~---~--~~ 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: debugging the browser started by UI tests
On windows just use windbg, and tell it to attach to child processes. I can show you if you want. Nicolas On Tue, Sep 22, 2009 at 4:10 PM, Scott Violet s...@chromium.org wrote: WAIT_FOR_DEBUGGER_ON_OPEN predates the Linux port. It may work on Linux, I just haven't tried it. -Scott On Tue, Sep 22, 2009 at 4:06 PM, Evan Martin e...@chromium.org wrote: Both of these should go to the ui tests section of the debugging wiki, which is where I turned in attempting to answer Pawel's question: http://code.google.com/p/chromium/wiki/LinuxDebugging#UI_tests On Tue, Sep 22, 2009 at 4:03 PM, Scott Violet s...@chromium.org wrote: If you uncomment WAIT_FOR_DEBUGGER_ON_OPEN on ui_test you'll be prompted. We really need to convert this into a comment line option. -Scott On Tue, Sep 22, 2009 at 3:00 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: What's the best way to attach the debugger to a browser started by a UI test? How about doing that only in case of a crash? I'm looking for solution both for Windows and Linux, so if you have good techniques, it'd be really nice. I can even document them on the wiki, but currently I'm using LOG statements when debugging the browser (I know it's not the optimal and kind of sucks, but I couldn't find a good way to attach the debugger). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Webkit merges and tree closures
Hi, In the last few weeks I've been trying to be aware as much as possible about the reasons we close the tree, and my gut feeling seems to match what I'm seeing: Webkit merges is the main cause. Now, I understand that Webkit merges are not easy, and really, kudos to the team for keeping up with this and doing this constant work, but I think there are some ways we can make it a little bit more seamless for the rest of us. Today is a good example, the tree was red for 3 hours, from 2:30PM pacific to 5:30PM. This also coincide with the peak hours where chromium developers work and need the tree to be open. And as I said, today is just an example, and I don't want to sound rude to whoever did the merge, this is not his fault. Overview of the day: 2 PM : webkit merge committed 2:30 : a bunch of bots turn red 3 PM : two failing ui tests are disabled by the webkit sheriff 3:41 : 21 layout tests are disabled by the webkit sheriff 4 PM : 2 new valgrind errors are disabled by the sheriff (not webkit sheriff) 4:36 : 3 new purify UMR are disable by the sheriff (not webkit sheriff) 4:38: 1 more layout test is disabled by the sheriff (not webkit sheriff) 5:04: 3 new selenium tests are disabled by the sheriff (not webkit sheriff) 5:30: Tree is open There has to be a better way to handle this. Bad webkit rolls happen. There is not much we can't do, but we can try to limit the damage. There are some tools we developed to help make your job easier please use them. 1. Try servers. (this should have caught the ui tests failures) 2. On demand try server for the layout tests (this should have caught a bunch of other layout tests failures) And, as with other changes, the current rules apply: Monitor the tree after your change. You don't have anything better to do than to make it green. Seriously. If there are failures, add them to the expectation list right away (or revert, but with webkit merges this is not really an option). When the tree is red, this is not a good time to start investigate! You can do that later. If you did cause the tree to be red, please stick around until it's green. Maybe you fix, or test disabling will uncover yet another failing test. You might also check back again ~30 minutes to an hour after to make sure some flakiness was not introduced. purify and valgrind redness count. Treat them the same way as the other tests. Don't expect the sheriff to hold your hand. In the timeline above, in the last hour the sheriff had to clean up after the webkit merge. This is not his job. (But he has to do it when you don't!) In the green tree task force we have an OKR to enforce that people take care of their failures within 10 minutes after the tree turns red. Webkit merges are not going to be an exception. If this is an issue, I am proposing that Webkit merges be done outside peak hours (11am-5pm pacific). Oh, and, if your change turned the tree red for 3 hours, don't be mad at the sheriff when he pings you repeatedly about the status of the fix. His job is to keep the tree green and running. He does not care about your change. Thoughts? Nicolas --~--~-~--~~~---~--~~ 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: Webkit merges and tree closures
On Tue, Sep 22, 2009 at 5:40 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: If this is an issue, I am proposing that Webkit merges be done outside peak hours (11am-5pm pacific). If we implement this, it can cause problems for cases where we need to do a merge/land/merge pattern to coordinate landing a local and upstream fix without having the canary bot broken for hours (which is really bad). I think we'll have to allow merges to land during daytime hours. We should definitely document on the WebKit Merge wiki/dev site page the best practices for running the merge through various try servers, even if that info is already available elsewhere. PK --~--~-~--~~~---~--~~ 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: Webkit merges and tree closures
On Tue, Sep 22, 2009 at 17:40, Nicolas Sylvain nsylv...@chromium.orgwrote: 3 PM : two failing ui tests are disabled by the webkit sheriff I was looking at the UI tests and it wasn't immediately obvious that a webkit update might break them. Can we run all the UI tests on the webkit canary bot? If that takes too long, we can selectively exclude the slow tests, based on http://build.chromium.org/buildbot/slowness-report/ By the way, the layout test failures... can we catch them on the webkit canary bot(s)? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
Today wasn't a happy day for p...@. He did a seemingly innocuous roll that broke the world: selenium, ui tests, layout tests. I am sure it was stressful and probably added unnecessary gray to his hair. Stuff like this happens to WebKit gardeners. We're used to breakages upstream. That's the cost of being unforked, right? The problem however, is that since we unforked, most of these breakages and regressions are caused by fellow teammates. There are two major issues: 1) writers of patches don't mention that the patch is two-sided and will break Chromium if landed prematurely. I don't have to go far for an example. Commit queue bot landed http://trac.webkit.org/changeset/48659 a few minutes ago and broke the canary. This means that the canary will be red all night and any subsequent regressions will either not be noticed or create more complications. 2) writers of patches don't test them properly. In Paul's case, it was http://trac.webkit.org/changeset/48639, again by a teammate, and it looks like the patch wasn't very thoroughly tested -- it showed a few regressions in the canary, but because it had to do with V8 garbage collection, the failures were intermittent and seemingly random. However, landing it on trunk looked like a shrapnel blast. This all means that we have to be a bit more diligent. We shouldn't be paying these unnecessary costs. So, from now on, I propose a fairly simple set of new rules: 1) if you write a Chromium patch for WebKit, you must provide URLs of successful trybot runs with your submission. Chromium WebKit reviewers will not r+ your patch otherwise. If you can't provide the trybot URLs for some reason, please explain in detail why this patch could still land. 2) if the two-sided patch you authored broke the canary and this happened with no coordination with the WebKit gardener, you assume WebKit gardening responsibility for the next 24 hours. Hopefully, these amendments to our existing ways will bring a bit more peace and stability to the Chromium land. What do you think? :DG :DG --~--~-~--~~~---~--~~ 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: Webkit merges and tree closures
On Tue, Sep 22, 2009 at 5:40 PM, Nicolas Sylvain nsylv...@chromium.org wrote: If this is an issue, I am proposing that Webkit merges be done outside peak hours (11am-5pm pacific). This seems backwards. Don't we want to integrate more often so we can catch and fix these issue faster? Ideally, we'll be able to merge with every webkit.org commit once we get the WebKit API in place. Adam --~--~-~--~~~---~--~~ 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: Webkit merges and tree closures
There are 2 major issues here (besides leaving things for the Sheriff to clean up): 1) a lot of the gardeners are inexperienced and drop the ball. This has bitten us many times. The last time we had a big string of problems related to this, I meant to send out an email giving people advice on what to expect and how to prepare. I will do it this time. Hopefully people listen. 2) we don't have enough tools for gardeners to do their jobs. As I mentioned in another thread you started the other day, we really need more try bots and/or canaries that run memory tests, our full suite of tests, etc. Without that, things are not going to get better. Just to be clear, on bad days, gardening is WAY harder than sheriffing by yourself. Like you mentioned, reverting a merge is pretty much not an option because you only get further behind, which makes things harder. If several hour tree closures once or twice a week are not an option, then we need more bots. J On Tue, Sep 22, 2009 at 5:50 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: On Tue, Sep 22, 2009 at 17:40, Nicolas Sylvain nsylv...@chromium.orgwrote: 3 PM : two failing ui tests are disabled by the webkit sheriff I was looking at the UI tests and it wasn't immediately obvious that a webkit update might break them. Can we run all the UI tests on the webkit canary bot? If that takes too long, we can selectively exclude the slow tests, based on http://build.chromium.org/buildbot/slowness-report/ By the way, the layout test failures... can we catch them on the webkit canary bot(s)? --~--~-~--~~~---~--~~ 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: Webkit merges and tree closures
On Tue, Sep 22, 2009 at 6:08 PM, Adam Barth aba...@chromium.org wrote: On Tue, Sep 22, 2009 at 5:40 PM, Nicolas Sylvain nsylv...@chromium.org wrote: If this is an issue, I am proposing that Webkit merges be done outside peak hours (11am-5pm pacific). This seems backwards. Don't we want to integrate more often so we can catch and fix these issue faster? Ideally, we'll be able to merge with every webkit.org commit once we get the WebKit API in place. I really want to stress the first part of my sentence: if this is an issue . For small webkit merges, I really don't expect this to be an issue. Once the API is in place, I'm pretty sure we won't have this problem. Or at least not as often. Nicolas Adam --~--~-~--~~~---~--~~ 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: Webkit merges and tree closures
On Tue, Sep 22, 2009 at 6:08 PM, Adam Barth aba...@chromium.org wrote: On Tue, Sep 22, 2009 at 5:40 PM, Nicolas Sylvain nsylv...@chromium.org wrote: If this is an issue, I am proposing that Webkit merges be done outside peak hours (11am-5pm pacific). This seems backwards. Don't we want to integrate more often so we can catch and fix these issue faster? Ideally, we'll be able to merge with every webkit.org commit once we get the WebKit API in place. Indeed. I would rather see small rolls throughout the day. Trying to accumulate them into larger spans will result in larger blasts. :DG --~--~-~--~~~---~--~~ 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: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
On Tue, Sep 22, 2009 at 6:06 PM, Dimitri Glazkov dglaz...@google.comwrote: Today wasn't a happy day for p...@. He did a seemingly innocuous roll that broke the world: selenium, ui tests, layout tests. I am sure it was stressful and probably added unnecessary gray to his hair. Stuff like this happens to WebKit gardeners. We're used to breakages upstream. That's the cost of being unforked, right? The problem however, is that since we unforked, most of these breakages and regressions are caused by fellow teammates. There are two major issues: 1) writers of patches don't mention that the patch is two-sided and will break Chromium if landed prematurely. I don't have to go far for an example. Commit queue bot landed http://trac.webkit.org/changeset/48659 a few minutes ago and broke the canary. This means that the canary will be red all night and any subsequent regressions will either not be noticed or create more complications. 2) writers of patches don't test them properly. In Paul's case, it was http://trac.webkit.org/changeset/48639, again by a teammate, and it looks like the patch wasn't very thoroughly tested -- it showed a few regressions in the canary, but because it had to do with V8 garbage collection, the failures were intermittent and seemingly random. However, landing it on trunk looked like a shrapnel blast. This all means that we have to be a bit more diligent. We shouldn't be paying these unnecessary costs. So, from now on, I propose a fairly simple set of new rules: 1) if you write a Chromium patch for WebKit, you must provide URLs of successful trybot runs with your submission. Chromium WebKit reviewers will not r+ your patch otherwise. If you can't provide the trybot URLs for some reason, please explain in detail why this patch could still land. This will take some getting used to, but is probably for the best. Where are the instructions for trying WebKit and 2 sided patches again? 2) if the two-sided patch you authored broke the canary and this happened with no coordination with the WebKit gardener, you assume WebKit gardening responsibility for the next 24 hours. Definitely. I also think the gardener reserves the right to revert any WebKit patch landed by a Chromium contributor. Hopefully, these amendments to our existing ways will bring a bit more peace and stability to the Chromium land. 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-dev] Re: Webkit merges and tree closures
On Tue, Sep 22, 2009 at 6:16 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: On Tue, Sep 22, 2009 at 6:10 PM, Jeremy Orlow jor...@chromium.org wrote: There are 2 major issues here (besides leaving things for the Sheriff to clean up): 1) a lot of the gardeners are inexperienced and drop the ball. This has bitten us many times. The last time we had a big string of problems related to this, I meant to send out an email giving people advice on what to expect and how to prepare. I will do it this time. Hopefully people listen. 2) we don't have enough tools for gardeners to do their jobs. As I mentioned in another thread you started the other day, we really need more try bots and/or canaries that run memory tests, our full suite of tests, etc. Without that, things are not going to get better. Just to be clear, on bad days, gardening is WAY harder than sheriffing by yourself. Like you mentioned, reverting a merge is pretty much not an option because you only get further behind, which makes things harder. If several hour tree closures once or twice a week are not an option, then we need more bots. We are creating bots as fast as we can. We delivered almost (all?) of them you asked for. You have purify canary, valgrind canary, perf tests canary, and selenium tests canary. You also have the layout tests try slaves, and the valgrind try slave. I guess the one that remains in ui tests? We can work on that and make it happen. (which you have a try server for in the mean time). Sorry, I haven't gardened in a month or so, so I'm obviously behind the times. These will DEFINITELY help. :-) Nicolas J On Tue, Sep 22, 2009 at 5:50 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: On Tue, Sep 22, 2009 at 17:40, Nicolas Sylvain nsylv...@chromium.orgwrote: 3 PM : two failing ui tests are disabled by the webkit sheriff I was looking at the UI tests and it wasn't immediately obvious that a webkit update might break them. Can we run all the UI tests on the webkit canary bot? If that takes too long, we can selectively exclude the slow tests, based on http://build.chromium.org/buildbot/slowness-report/ By the way, the layout test failures... can we catch them on the webkit canary bot(s)? --~--~-~--~~~---~--~~ 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: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
On Tue, Sep 22, 2009 at 6:06 PM, Dimitri Glazkov dglaz...@google.comwrote: Today wasn't a happy day for p...@. He did a seemingly innocuous roll that broke the world: selenium, ui tests, layout tests. I am sure it was stressful and probably added unnecessary gray to his hair. Stuff like this happens to WebKit gardeners. We're used to breakages upstream. That's the cost of being unforked, right? The problem however, is that since we unforked, most of these breakages and regressions are caused by fellow teammates. There are two major issues: 1) writers of patches don't mention that the patch is two-sided and will break Chromium if landed prematurely. I don't have to go far for an example. Commit queue bot landed http://trac.webkit.org/changeset/48659 a few minutes ago and broke the canary. This means that the canary will be red all night and any subsequent regressions will either not be noticed or create more complications. 2) writers of patches don't test them properly. In Paul's case, it was http://trac.webkit.org/changeset/48639, again by a teammate, and it looks like the patch wasn't very thoroughly tested -- it showed a few regressions in the canary, but because it had to do with V8 garbage collection, the failures were intermittent and seemingly random. However, landing it on trunk looked like a shrapnel blast. This all means that we have to be a bit more diligent. We shouldn't be paying these unnecessary costs. So, from now on, I propose a fairly simple set of new rules: 1) if you write a Chromium patch for WebKit, you must provide URLs of successful trybot runs with your submission. Chromium WebKit reviewers will not r+ your patch otherwise. If you can't provide the trybot URLs for some reason, please explain in detail why this patch could still land. Is this even possible? i.e. I had uploaded a WebKit patch on codereview but none of the patchsets got run on the try server http://codereview.chromium.org/178030/show 2) if the two-sided patch you authored broke the canary and this happened with no coordination with the WebKit gardener, you assume WebKit gardening responsibility for the next 24 hours. Hopefully, these amendments to our existing ways will bring a bit more peace and stability to the Chromium land. What do you think? :DG :DG --~--~-~--~~~---~--~~ 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: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
On Tue, Sep 22, 2009 at 6:25 PM, John Abd-El-Malek j...@chromium.org wrote: Is this even possible? i.e. I had uploaded a WebKit patch on codereview but none of the patchsets got run on the try server http://codereview.chromium.org/178030/show It is possible: aba...@zenque:~/svn/kr/src/third_party/WebKit$ gcl try scriptcontext --use_svn --svn_repo=svn://svn.chromium.org/chrome-try/try --bot layout_win,layout_mac,layout_linux --root src/third_party --~--~-~--~~~---~--~~ 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: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
On Tue, Sep 22, 2009 at 6:35 PM, Adam Barth aba...@chromium.org wrote: On Tue, Sep 22, 2009 at 6:25 PM, John Abd-El-Malek j...@chromium.org wrote: Is this even possible? i.e. I had uploaded a WebKit patch on codereview but none of the patchsets got run on the try server http://codereview.chromium.org/178030/show It is possible: aba...@zenque:~/svn/kr/src/third_party/WebKit$ gcl try scriptcontext --use_svn --svn_repo=svn://svn.chromium.org/chrome-try/try --bot layout_win,layout_mac,layout_linux --root src/third_party And if you use git, there was another thread today about this on chromium-dev : http://groups.google.com/group/chromium-dev/browse_thread/thread/c481ecc1842ddfe4# http://groups.google.com/group/chromium-dev/browse_thread/thread/c481ecc1842ddfe4# Nicolas --~--~-~--~~~---~--~~ 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: Q about closing valgrind issues
I didn't say it would be easy. ;-) I also wouldn't be surprised if window position varied across unit test runs. I think my main point here wasn't to drop everything you're doing to track this down. I'm just saying that it's a dangerous bug to throw into the supression list and forget about. Erik On Tue, Sep 22, 2009 at 11:11 AM, Avi Drissman a...@google.com wrote: If this is caught in the unit tests ~1/30 times, then it's happening despite the window positionings and view positionings being the same. There's multiple layers of indirection in there (two context types, four libraries) all totally closed source. Tracking it down feels like it would take way too much effort and I'm swamped. If you have some spare time... Avi On Tue, Sep 22, 2009 at 11:56 AM, Erik Kay erik...@chromium.org wrote: I'd suspect an alignment / positioning bug for what you're seeing. Often rect fill algorithms have several paths with different loop unrolling tricks based on the size and position of the rect. I agree with Evan that it may be worth tracking this down a bit more. Even if it's not our bug, we need to find a way to avoid the memory stomping. I'm nervous about adding this to the upstream suppression list. I think that's OK to do for memory leaks, or for memory errors where it's been demonstrated that the result of the error is benign (like the UMRs in parts of Microsoft's STL implementation), but it doesn't seem like this fits into that case. Erik On Mon, Sep 21, 2009 at 1:15 PM, Avi Drissman a...@google.com wrote: I have no evidence to confirm/deny that. Even so it deserves an upstreaming. I'll look at it but why would it show up 1/30 times? Avi On Mon, Sep 21, 2009 at 4:07 PM, Evan Martin e...@chromium.org wrote: Could it possibly be related to passing a zero-sized rect in somewhere? On Mon, Sep 21, 2009 at 12:27 PM, Avi Drissman a...@google.com wrote: crbug.com/18189 crbug.com/18539 I got the first because it involved the status bubble; I got the second because I got the first. NSRectFill(). Deep down that ends up in sseCGSFill8by1, which looks like it sometimes scribbles off the end of some buffer. I have no idea what we could be doing wrong to cause it nor what we could be doing to affect it at all. I want to just dup one to the other and mark both as CANNOTFIXBADAPPLECODE^WWontFix. Any objections? Avi --~--~-~--~~~---~--~~ 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: Webkit merges and tree closures
Actionable items for keeping the tree green (in addition to blaming the WebKit gardener for [insert action here]): - *Get people putting in chromium patches upstream to run their changes through trybots, etc*. imo, patches from @chromium folks cause well over 50% of the grief with WebKit rolls (and usually the worst issues like today). - As Adam suggested, *make changes to the WebKit commit queue to run items through the chromium try bots*. - *WebKit gardeners should be able to submit high priority jobs to the try bots*. These jobs should job to the front of any queues so that they run asap. Why? Time is critical when doing the gardening because if you find a breakage upstream, you need to check in a fix and then roll to that fix. The longer the delay, the more likely another breakage will be checked in. - *Consider auto-rolling WebKit deps*. Have the something like a parallel buildbot that runs against tip of tree WebKit. If everything passes except layout tests, add any layout test failures to test_expectations.txt (if there are less than 15) and roll DEPS on passing. If things fail, then turn red. - *Make it easier/faster to disable tests and file bugs about them *(using the last person in the blame/annotate for the test as the initial assignee or auto-assign it to the sheriff so (s)he can assign it to the right person) * *because issues will slip from WebKit rolls even though the gardeners try to be thorough. Also, this should help with turning the tree green in other cases as well. The sheriff (and everyone on the chromium team) should care about the WebKit roll as this is critical to the success of this project. Frequent rolls, should isolate issues and hopefully help to keep the tree green. * * To help shed some light on why WebKit gardening is more painful than sheriffing: 1. WebKit gardeners are all alone in trying to deal with things. 2. When things go bad on the canary, no one shuts down the tree for you and any changes to help with merging are not given priority (if the tree is red and you have an innocuous change to fix the webkit merge, you won't get it in.) 3. When tests fail anywhere (on the canary, when committing the roll, etc.), you have to figure out why, typically for a lot of changes that you know nothing about. 4. Two days of gardening -- multiple days of clean up afterward. 5. WebKit gardening occurs more often than sheriff duties. 6. afaik all WebKit gardeners also have sheriff duties. Net: chromium sheriffs please be willing to give a little extra help to the WebKit gardener. Remember that their hair is turning white as they try to run in front of a locomotive. Dave --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
