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
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.
E
On Tue, Sep 22, 2009 at 6:35 PM, Adam Barth wrote:
>
> On Tue, Sep 22, 2009 at 6:25 PM, John Abd-El-Malek
> 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
On Tue, Sep 22, 2009 at 6:25 PM, John Abd-El-Malek 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$
On Tue, Sep 22, 2009 at 6:06 PM, Dimitri Glazkov wrote:
>
> 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 W
On Tue, Sep 22, 2009 at 6:16 PM, Nicolas Sylvain wrote:
>
>
> On Tue, Sep 22, 2009 at 6:10 PM, Jeremy Orlow 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 m
On Tue, Sep 22, 2009 at 6:15 PM, Dimitri Glazkov wrote:
> I think this is the key point. This is a temporary situation. The
> biggest issue is that _we_ as a team are the key aggravators of the
> issue. Let's solve it by being more diligent on the upstream side,
> because that's where we'll live
On Tue, Sep 22, 2009 at 6:06 PM, Dimitri Glazkov wrote:
>
> 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 W
On Tue, Sep 22, 2009 at 6:06 PM, Dimitri Glazkov wrote:
> 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, plea
On Tue, Sep 22, 2009 at 6:10 PM, Jeremy Orlow 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
>
On Tue, Sep 22, 2009 at 6:10 PM, Nicolas Sylvain wrote:
>
>
> On Tue, Sep 22, 2009 at 6:08 PM, Adam Barth wrote:
>>
>> On Tue, Sep 22, 2009 at 5:40 PM, Nicolas Sylvain
>> wrote:
>> > If this is an issue, I am proposing that Webkit merges be done outside
>> > peak
>> > hours (11am-5pm pacific).
On Tue, Sep 22, 2009 at 6:08 PM, Adam Barth wrote:
>
> On Tue, Sep 22, 2009 at 5:40 PM, Nicolas Sylvain
> 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
On Tue, Sep 22, 2009 at 6:08 PM, Adam Barth wrote:
> On Tue, Sep 22, 2009 at 5:40 PM, Nicolas Sylvain
> 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 ca
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 wha
On Tue, Sep 22, 2009 at 5:40 PM, Nicolas Sylvain 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 me
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
On Tue, Sep 22, 2009 at 17:40, Nicolas Sylvain wrote:
> 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 l
On Tue, Sep 22, 2009 at 5:40 PM, Nicolas Sylvain wrote:
> 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 a
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 t
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 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,
WAIT_FOR_DEBUGGER_ON_OPEN adds an extra timeout in waiting for the
process to start.
-Scott
On Tue, Sep 22, 2009 at 4:18 PM, Tim Steele wrote:
> What's the difference between WAIT_FOR_DEBUGGER_ON_OPEN and
> --wait-for-debugger / wait-for-debugger-children for renderers?
>
> On Tue, Sep 22, 20
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 wrote:
>
> If you uncomment WAIT_FOR_DEBUGGER_ON_OPEN on ui_test you'll be
> prompted. We really need to convert this into a c
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 wrote:
>
> If you uncomme
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 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
> q
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 wrote:
>
> If you uncomment WAIT_FOR_DEBUGGER_ON
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.
wrote:
> What's the best way to attach the debugger to a browser started by a UI
> test? How about doin
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.
wrote:
> What's the best way to at
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
V8GCCont
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
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 sta
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 wrote:
>
> Are there a
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
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
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 supe
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 wrote:
>
> Yep. Dirk was the one to suggest bringing it back. I didn't put this
> in the documentat
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/vi
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 wrote:
>
> After hitting this message about twenty times over the last couple days,
> and getting pinged by various people a
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
nati
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(
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.
--~--~-~--~~
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 wrote:
> On Tue, Sep 22, 2009 at 10:26 AM, Jeffr
On Tue, Sep 22, 2009 at 10:26 AM, Jeffrey Chang 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.
>- Se
I wasn't really trying to relay the explicits since there are a few. :)
And example is the generate_localizer action on the 'browser' target in the
chrome project. It has all it's inputs/outputs, and it runs when needed.
But the source file that includes it's output, doesn't always recompile
whe
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
On Tue, Sep 22, 2009 at 10:39 AM, Daniel Cowx 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
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 y
On Mon, Sep 21, 2009 at 10:53 AM, Antony Sargent wrote:
> 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
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-
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:
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
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
wrote:
> I've confirmed this with
On Mon, Sep 21, 2009 at 4:52 AM, Elliot Glaysher (Chromium)
wrote:
>
> On Sun, Sep 20, 2009 at 7:43 PM, Evan Martin 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?
>
Thank you so much for doing this!
:DG<
On Tue, Sep 22, 2009 at 9:39 AM, Yaar Schnitman 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 pos
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
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
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 nee
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 thro
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
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
wrote:
> I've confirmed this wi
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 cha
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 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
> >
Thanks, I'll try.
James Su
2009/9/22 Dan Kegel
> On Tue, Sep 22, 2009 at 12:07 AM, James Su 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': {
> 'r
On Tue, Sep 22, 2009 at 12:07 AM, James Su 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-frobo
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 u
64 matches
Mail list logo