[chromium-dev] Re: Make PostTask virtual?
+1 Darin +1 Maruel It was/is impressively hard to modify the message loop/pump without harming performance, and that performance is so central, that it tends to be visible in top level browser benchmarks. It was very difficult to make this body of code as simple() as it is. ...and it is not very simple. Please try not to add any complexity in what is seemingly super subtle code. Adding and calling through virtual methods may have some impact, and should be done very cautiously. Virtualizing existing methods, if they are mainstream, is pretty much guaranteed to impact performance. Adding interfaces, as proposed by Darin, would be seemingly risk free, at least in terms of performance. Jim On Tue, Aug 4, 2009 at 11:04 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: On Tue, Aug 4, 2009 at 2:01 PM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote: On Tue, Aug 4, 2009 at 6:28 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: I'm slightly against. No real reason :) except that it'll definitely bloat the WPO build. How bad would the bloat be? Please get data by building both with and without the virtual keyword in official/wpo (not release) build. M-A --~--~-~--~~~---~--~~ 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: Urgent, a very evil site i think which does evil things (no joke)
On Tue, Aug 4, 2009 at 11:29 PM, Ian Fettei...@chromium.org wrote: So far as I can tell, the page is not instantiating Java. it's instantiating acrobat / flash, and perhaps that instantiates java? At any rate, so far as I can tell there's little that can be done here. I presume you mean little to be done in chromium? Has anyone reported the problem(s) to adobe? 2009/8/4 nakro yoav.zilberb...@gmail.com Ok, but just so you know, i also checked this site again(!) with the -- safe-plugins switch and since i had Process Explorer open with always on top, and since sun java's dies with this safe-plugins mode it would seem that it was java who triggered this mess, and since you do not ask for permissions to run java code with chrome, it is a bit creepy but ok, if you say this is kosher, i take your word for it --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Chrome Sync question
Hello, I've recently read news about a new feature going into Chromium that allows bookmarks to be synchronized online. Is this feature currently available in a CI build of Chromium? If not, are there any speculations as to when this feature will be ready for testing/usage? 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: Chrome Sync question
Hi Robert, Yes, we are preparing to start letting users test Chrome Bookmark Sync really soon. We landed a portion of the code in trunk yesterday (behind an #ifdef), but there is no Chromium ToT build as of yet. Please stay tuned as this feature will go to the Dev Channel once it is ready for public consumption. You can find more details about our plan here: http://groups.google.com/group/chromium-dev/browse_thread/thread/bdacc1bdf3c5cb6a On Wed, Aug 5, 2009 at 8:52 AM, Robert Dailey rcdai...@gmail.com wrote: Hello, I've recently read news about a new feature going into Chromium that allows bookmarks to be synchronized online. Is this feature currently available in a CI build of Chromium? If not, are there any speculations as to when this feature will be ready for testing/usage? Thanks! -- -Idan --~--~-~--~~~---~--~~ 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: browser/sync is moving in
People have plenty of bookmarks on IE using Google Toolbar. Will these be synced with Chrome bookmarks as well? A lot of google users were left out in the cold when switching from IE+GToolbar to Chrome, as we had to leave our google bookmarks behind and start fresh (even tho IE bookmarks could be imported into Chrome bookmarks from day one!). Seems about time to show a little love to the google faithful, and sync Chrome and IE Google Toolbar bookmarks right off the bat-- you could implement a similar method as Gmail's merge contacts feature, allowing the user to eliminate duplicate entries himself. just a suggestion. 10 On Jul 31, 5:07 pm, Tim Steele t...@chromium.org wrote: Hi! A bunch of us have been working on a feature to sync user data in Chromium with a Google account. (Surprise! :)) The great news is that we'll be starting to work directly in the Chromium project this week, and let me tell you, are we excited to do that! This email discusses how we're planning to get started, in detail (maybe too much detail... sorry). We have built a library that implements the client side of our sync protocolhttp://sites.google.com/a/chromium.org/dev/developers/design-document..., as well as the Google server-side infrastructure to serve Google Chrome users and synchronize data to their Google Account. Of course, all the code going into Chromium is open source, and the messages between the client and server use the open protobuf http://code.google.com/p/protobuf/ format and library. Check out the sync developer pagehttp://sites.google.com/a/chromium.org/dev/developers/design-document... if you're interested in low-level goals and technical details. We will be landing this code in a few steps rather than one giant changelist for a number of reasons. First, this makes reviewing a *lot* easier; it isn't the most straightforward code by nature, so the more fine grained scrutiny the code gets, the better. Second, we've been working in a proprietary environment until now because of the dependency of having to build the complementary Google production server environment for syncing. As such, the code uses a small number of internal libraries that we need to open-source or replace, as well as libraries that would be redundant to what Chromium already includes. Removing these, and open sourcing the entire sync engine, is our highest priority and we expect this to take about three weeks. So how will we commit the code in pieces and not totally hose the build in the process? First, a little more background. You may have come across the CHROME_PERSONALIZATION #define when digging through Chromium source code. Right now, this is used in conjunction with a relatively small number of private c++ source files to conditionally build Chromium with sync enabled. These files are in fact a glue layer between Chromium and what is called the syncapi, which is the bulk of the client library I was talking about above. On windows, syncapi is built into a DLL, and when CHROME_PERSONALIZATION is defined this DLL gets placed alongside chrome.dll for use at runtime. Syncapi builds and runs on Linux, but not Mac (yet). With the initial checkin, we will leave the CHROME_PERSONALIZATION #define as-is, so the sync code will not be built by default. We'll be working hard over the coming weeks to make sure the code passes all existing test suites that are part of the regular buildbot cycle, and on removing the #define. After that, our hope is that we will be free of the DLL altogether and have all the code checked in to the repository, fully functional or not, in a few weeks. We do *not* plan on ever checking in the windows-only syncapi dll to the main chromium repository. So until the dll is no longer needed, the public repository won't have all the bits to actually build Chromium with sync enabled. That said, we want to keep the sync build running smoothly, so we will use a combination of command-line flag (to enable sync) and delay-loading syncapi.dll only when it is needed. This will allow the glue code to compile as part of the normal Chromium build without introducing a dependency on this dll, yet still make it possible to run with the dll present. On that note, we're planning to use the syncapi DLL to produce a sync-enabled Google Chrome build for dev-channel users in a week or so, to get the feature into experimentally inclined hands. We have a great deal of infrastructure, both in the browser and in the form of production Google services, that need to start seeing real user traffic and usage. It takes a great deal of testing and confidence inspired by real usage statistics before any complex system like this can be deemed adequate for use by a large user base. So if we want to let all Google Chrome users use sync (and we do! we do!), we've got to get started on this pronto. Our developer
[chromium-dev] Re: browser/sync is moving in
great
On Jul 31, 6:07 pm, Tim Steele t...@chromium.org wrote:
Hi!
A bunch of us have been working on a feature to sync user data in Chromium
with a Google account. (Surprise! :)) The great news is that we'll be
starting to work directly in the Chromium project this week, and let me tell
you, are we excited to do that! This email discusses how we're planning to
get started, in detail (maybe too much detail... sorry).
We have built a library that implements the client side of our sync
protocolhttp://sites.google.com/a/chromium.org/dev/developers/design-document...,
as well as the Google server-side infrastructure to serve Google Chrome
users and synchronize data to their Google Account. Of course, all the code
going into Chromium is open source, and the messages between the client and
server use the open protobuf http://code.google.com/p/protobuf/ format and
library. Check out the sync developer
pagehttp://sites.google.com/a/chromium.org/dev/developers/design-document...
if
you're interested in low-level goals and technical details.
We will be landing this code in a few steps rather than one giant changelist
for a number of reasons. First, this makes reviewing a *lot* easier; it
isn't the most straightforward code by nature, so the more fine grained
scrutiny the code gets, the better. Second, we've been working in a
proprietary environment until now because of the dependency of having to
build the complementary Google production server environment for syncing.
As such, the code uses a small number of internal libraries that we need to
open-source or replace, as well as libraries that would be redundant to what
Chromium already includes. Removing these, and open sourcing the entire
sync engine, is our highest priority and we expect this to take about three
weeks.
So how will we commit the code in pieces and not totally hose the build in
the process? First, a little more background. You may have come across the
CHROME_PERSONALIZATION #define when digging through Chromium source code.
Right now, this is used in conjunction with a relatively small number of
private c++ source files to conditionally build Chromium with sync enabled.
These files are in fact a glue layer between Chromium and what is called
the syncapi, which is the bulk of the client library I was talking about
above. On windows, syncapi is built into a DLL, and when
CHROME_PERSONALIZATION is defined this DLL gets placed alongside chrome.dll
for use at runtime. Syncapi builds and runs on Linux, but not Mac (yet).
With the initial checkin, we will leave the CHROME_PERSONALIZATION #define
as-is, so the sync code will not be built by default. We'll be working hard
over the coming weeks to make sure the code passes all existing test suites
that are part of the regular buildbot cycle, and on removing the #define.
After that, our hope is that we will be free of the DLL altogether and have
all the code checked in to the repository, fully functional or not, in a few
weeks. We do *not* plan on ever checking in the windows-only syncapi dll to
the main chromium repository. So until the dll is no longer needed, the
public repository won't have all the bits to actually build Chromium with
sync enabled. That said, we want to keep the sync build running smoothly,
so we will use a combination of command-line flag (to enable sync) and
delay-loading syncapi.dll only when it is needed. This will allow the
glue code to compile as part of the normal Chromium build without
introducing a dependency on this dll, yet still make it possible to run with
the dll present.
On that note, we're planning to use the syncapi DLL to produce a
sync-enabled Google Chrome build for dev-channel users in a week or so, to
get the feature into experimentally inclined hands. We have a great deal of
infrastructure, both in the browser and in the form of production Google
services, that need to start seeing real user traffic and usage. It takes a
great deal of testing and confidence inspired by real usage statistics
before any complex system like this can be deemed adequate for use by a
large user base. So if we want to let all Google Chrome users use sync (and
we do! we do!), we've got to get started on this pronto.
Our developer
pagehttp://sites.google.com/a/chromium.org/dev/developers/design-document...
also
covers the hierarchy of files we're landing that you can expect to start
syncing (in the gclient sense) down in the next couple of days. We can't
wait (*really*) to work on this with the rest of the Chromium community and
going even further in creating the best browzr ever!
Thanks for reading, and happy syncing!
- the cloudy bunch
{idana, nick, nickbaum, chee, munjal, brg, chron, zork, laforge, tejasshah,
tim} at chromium.org
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email
[chromium-dev] Re: browser/sync is moving in
People have plenty of bookmarks on IE using Google Toolbar. Will these be synced with Chrome bookmarks as well? A lot of google users were left out in the cold when switching from IE+GToolbar to Chrome, as we had to leave our google bookmarks behind and start fresh (even tho IE bookmarks could be imported into Chrome bookmarks from day one!). Seems about time to show a little love to the google faithful, and sync Chrome and IE Google Toolbar bookmarks right off the bat-- you could implement a similar method as Gmail's merge contacts feature, allowing the user to eliminate duplicate entries himself. just a suggestion. 10 On Jul 31, 5:07 pm, Tim Steele t...@chromium.org wrote: Hi! A bunch of us have been working on a feature to sync user data in Chromium with a Google account. (Surprise! :)) The great news is that we'll be starting to work directly in the Chromium project this week, and let me tell you, are we excited to do that! This email discusses how we're planning to get started, in detail (maybe too much detail... sorry). We have built a library that implements the client side of our sync protocolhttp://sites.google.com/a/chromium.org/dev/developers/design-document..., as well as the Google server-side infrastructure to serve Google Chrome users and synchronize data to their Google Account. Of course, all the code going into Chromium is open source, and the messages between the client and server use the open protobuf http://code.google.com/p/protobuf/ format and library. Check out the sync developer pagehttp://sites.google.com/a/chromium.org/dev/developers/design-document... if you're interested in low-level goals and technical details. We will be landing this code in a few steps rather than one giant changelist for a number of reasons. First, this makes reviewing a *lot* easier; it isn't the most straightforward code by nature, so the more fine grained scrutiny the code gets, the better. Second, we've been working in a proprietary environment until now because of the dependency of having to build the complementary Google production server environment for syncing. As such, the code uses a small number of internal libraries that we need to open-source or replace, as well as libraries that would be redundant to what Chromium already includes. Removing these, and open sourcing the entire sync engine, is our highest priority and we expect this to take about three weeks. So how will we commit the code in pieces and not totally hose the build in the process? First, a little more background. You may have come across the CHROME_PERSONALIZATION #define when digging through Chromium source code. Right now, this is used in conjunction with a relatively small number of private c++ source files to conditionally build Chromium with sync enabled. These files are in fact a glue layer between Chromium and what is called the syncapi, which is the bulk of the client library I was talking about above. On windows, syncapi is built into a DLL, and when CHROME_PERSONALIZATION is defined this DLL gets placed alongside chrome.dll for use at runtime. Syncapi builds and runs on Linux, but not Mac (yet). With the initial checkin, we will leave the CHROME_PERSONALIZATION #define as-is, so the sync code will not be built by default. We'll be working hard over the coming weeks to make sure the code passes all existing test suites that are part of the regular buildbot cycle, and on removing the #define. After that, our hope is that we will be free of the DLL altogether and have all the code checked in to the repository, fully functional or not, in a few weeks. We do *not* plan on ever checking in the windows-only syncapi dll to the main chromium repository. So until the dll is no longer needed, the public repository won't have all the bits to actually build Chromium with sync enabled. That said, we want to keep the sync build running smoothly, so we will use a combination of command-line flag (to enable sync) and delay-loading syncapi.dll only when it is needed. This will allow the glue code to compile as part of the normal Chromium build without introducing a dependency on this dll, yet still make it possible to run with the dll present. On that note, we're planning to use the syncapi DLL to produce a sync-enabled Google Chrome build for dev-channel users in a week or so, to get the feature into experimentally inclined hands. We have a great deal of infrastructure, both in the browser and in the form of production Google services, that need to start seeing real user traffic and usage. It takes a great deal of testing and confidence inspired by real usage statistics before any complex system like this can be deemed adequate for use by a large user base. So if we want to let all Google Chrome users use sync (and we do! we do!), we've got to get started on this pronto. Our developer
[chromium-dev] Re: Mystery error Assertion failed: (slab-magic == SLAB_MAGIC), function slab_alloc, file x-alloc.c, line 353.
On Tue, Aug 4, 2009 at 5:14 PM, Adam Langleya...@chromium.org wrote: On Tue, Aug 4, 2009 at 5:11 PM, Peter Kastingpkast...@google.com wrote: That is probably coming from the allocator underneath Chrome (presumably the one provided by the OS kernel). It probably means you have memory corruption that eventually leads to this. Yea, it does look a lot like it's from the kernel - but I don't think it is. SLAB was the kernel's default memory allocator for a long time, but SLAB_MAGIC isn't from the kernel sources (at least going back to 2005). Grepping every file on the system was the obvious thing to do; it found /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore So I guess some memory corruption bug (ours?) stepped on a slab used by Quartz. - Dan --~--~-~--~~~---~--~~ 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: AniWeather is back in 3.0.195.1!
Hi Johann, Thanks for reporting the issue. I traced and found that there is a new behavior in the latest Chrome that caused the issue. I still need some time to figure out whether this is a bug in Chrome yet. Anyway, I have worked around the issue in the webpage and it should work now. Please try it and let me know if you still have problems. -Jack On Aug 4, 11:03 pm, Johann esc...@gmail.com wrote: I can't change country, using dev 196.2 On Jul 28, 2:04 am, jack js2...@gmail.com wrote: Thanks to the latest progress in Chrome, AniWeather is back again to support the latest dev channel (3.0.195.1). Here are a few changes reflecting Chrome's recent progresses: 1. Use cookie instead of bookmark to save preferences. No more clumsy bookmark items. 2. Click a toolstrip icon to open according report. 3. Minor bug fixes. Check it atwww.aniweather.com. Enjoy and any comments are 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] [POSIX] Reworking our child process reaping
Our child process reaping is a little bit of a hack right now, which
is my fault. I didn't anticipate how bad it would turn out.
Currently, we use a bunch of hacks to make sure that we reap all the
children that we need to, but don't reap children from another part of
the code etc. If we need to make sure that a process dies within x
seconds, then we fork off a thread etc. process_util_posix.cc is scary
complex and bodgy.
Here's my plan:
We have a singleton object in base which handles all forking and reaping:
class ChildProcessReaper {
public:
// Has the same semantics as fork() - i.e. this function returns twice. In
// the parent process, the resulting child will be reaped on exit and the
// termination state will be saved. It can be accessed using
// GetTerminationState() below.
pid_t ForkAndRetainTerminationState(uint64_t* child_id);
// Same as ForkAndRetainTerminationState, but the child's termination state
// will not be retained on exit.
pid_t ForkAndForget(uint64_t* child_id);
// Get the termination state of a child started with
// ForkAndRetainTerminationState(). If the child has terminated, then ths
// function will return true and *status is set to the value obtained from
// wait(2).
bool GetTerminationState(uint64_t child_id, int* status);
// Wait |seconds| seconds for the given child to terminate. If it doesn't
// terminate within that amount of time, send SIGKILL. Calling this function
// is a no-op if the child has already terminated. If the child was created
// with ForkAndRetainTerminationState, then calling this function means that
// the child's terminate state will no longer be retained.
void EnsureChildTerminates(float seconds, uint64_t child_id);
This object is created in the IO thread of the browser. On Linux it'll
create a signalfd to get SIGCHILD. On OS X it'll spawn off a
PlatformThread which sits in wait(2) for child notifications. We can
then ensure that we'll never get zombies.
The only wrinkle is that we need to return both a pid_t and another id
(uint64_t above). Consider the following situation:
1) Thread A forks off a child, pid $x
2) The child runs, terminates and is reaped
3) Thread B forks off a child. Because $x has been reaped the kernel
is free to reuse that pid
Now, both thread A and B can call EnsureChildTerminates with pid $x
and kill the wrong child.
Any thoughts?
AGL
--~--~-~--~~~---~--~~
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: [POSIX] Reworking our child process reaping
On Wed, Aug 5, 2009 at 12:12 PM, Adam Langley a...@chromium.org wrote:
Our child process reaping is a little bit of a hack right now, which
is my fault. I didn't anticipate how bad it would turn out.
Currently, we use a bunch of hacks to make sure that we reap all the
children that we need to, but don't reap children from another part of
the code etc. If we need to make sure that a process dies within x
seconds, then we fork off a thread etc. process_util_posix.cc is scary
complex and bodgy.
Here's my plan:
We have a singleton object in base which handles all forking and reaping:
class ChildProcessReaper {
public:
// Has the same semantics as fork() - i.e. this function returns twice. In
// the parent process, the resulting child will be reaped on exit and the
// termination state will be saved. It can be accessed using
// GetTerminationState() below.
pid_t ForkAndRetainTerminationState(uint64_t* child_id);
// Same as ForkAndRetainTerminationState, but the child's termination
state
// will not be retained on exit.
pid_t ForkAndForget(uint64_t* child_id);
Why do you need a child_id if you're going to forget about it anyway?
// Get the termination state of a child started with
// ForkAndRetainTerminationState(). If the child has terminated, then ths
// function will return true and *status is set to the value obtained from
// wait(2).
bool GetTerminationState(uint64_t child_id, int* status);
// Wait |seconds| seconds for the given child to terminate. If it doesn't
// terminate within that amount of time, send SIGKILL. Calling this
function
// is a no-op if the child has already terminated. If the child was
created
// with ForkAndRetainTerminationState, then calling this function means
that
// the child's terminate state will no longer be retained.
void EnsureChildTerminates(float seconds, uint64_t child_id);
This object is created in the IO thread of the browser. On Linux it'll
create a signalfd to get SIGCHILD. On OS X it'll spawn off a
PlatformThread which sits in wait(2) for child notifications. We can
then ensure that we'll never get zombies.
The only wrinkle is that we need to return both a pid_t and another id
(uint64_t above). Consider the following situation:
1) Thread A forks off a child, pid $x
2) The child runs, terminates and is reaped
3) Thread B forks off a child. Because $x has been reaped the kernel
is free to reuse that pid
Now, both thread A and B can call EnsureChildTerminates with pid $x
and kill the wrong child.
Any thoughts?
Before Chrome I worked on an app that also forked off a LOT of processes and
had to keep track of their termination states. We did the exact same thing
you did here and it worked well. Only difference is that we did it in
Python. :-)
J
--~--~-~--~~~---~--~~
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: FYI: a new problem with the latest patch for 2008 SP1 (from today/yesterday)
I'm in trouble with this problem. Now the deque have this problem too. I already removed the SP1, the hotfix, reinstalled everything, but nothing works. On Jul 29, 11:28 pm, Lei Zhang thes...@chromium.org wrote: I assume there's a similar patch for VS2005SP1. Does that have the same problem? On Wed, Jul 29, 2009 at 11:15 AM, nakroyoav.zilberb...@gmail.com wrote: if you get the latest patch of VS2008SP1 (released yesterday) you will not be able to compile chrome you will get errors relating to '_Swap_adl' i googled it a bit, and till MS fixes it i simply modified 2 files in the inc dir tuple xutility and changed '_Swap_adl' to 'swap' - note the lowercase also due to permissions you might not be able to modify the file, so i did this in an elevated cmd prompt ok, now you know, here is where i got most of the info from http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/4bc93a... --~--~-~--~~~---~--~~ 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: [POSIX] Reworking our child process reaping
On Wed, Aug 5, 2009 at 12:21 PM, Jeremy Orlowjor...@chromium.org wrote: Why do you need a child_id if you're going to forget about it anyway? The thought was that one might want to call EnsureChildTerminates on it. If it turns out that nobody needs that I'll remove it. Cheers AGL --~--~-~--~~~---~--~~ 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 Mac Chrome in release mode
I just checked in r22506, which alters the structure of the application on disk on the Mac slightly. The entire program has moved into a dylib (framework) that lives within the app bundle, and the main executable is now a tiny stub that doesn't do anything but jump to the entry point in the dylib. I've got more related changes in the oven, but that's another story... The only noticeable change now from a development perspective is that gdb won't be able to find debugging symbols for the dylib when you're working in release mode. gdb looks for a dSYM bundle next to the framework, but we don't copy the dSYM into the app bundle (because we don't want it there). In case you need to debug a release-mode bundle, you'll need to place a symlink: cd xcodebuild ln -fs ../../../Chromium\ Framework.framework.dSYM Release/Chromium.app/Contents/Frameworks/ Then, when you debug Chromium.app: gdb Release/Chromium.app it will be able to load the framework's debugging symbols. I haven't used the Xcode debugger in a while, but the same symlink should work to get you on track there as well, since the Xcode debugger is just a gdb front-end. Mark --~--~-~--~~~---~--~~ 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: [POSIX] Reworking our child process reaping
On Wed, Aug 5, 2009 at 12:29 PM, Adam Langley a...@chromium.org wrote: On Wed, Aug 5, 2009 at 12:21 PM, Jeremy Orlowjor...@chromium.org wrote: Why do you need a child_id if you're going to forget about it anyway? The thought was that one might want to call EnsureChildTerminates on it. If it turns out that nobody needs that I'll remove it. Oh, I see. Makes sense. Even if no one uses it right away, I'd say leave it. --~--~-~--~~~---~--~~ 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: code coverage and browser_tests
Thanks. Can I just try adding browser_tests to the list and send you a CL if it works? On Tue, Aug 4, 2009 at 11:33, John Grabowski j...@chromium.org wrote: No. You can find the list of unittest files run by coverage in chrome.gyp; look at the end of chrome.gyp for the coverage target and list of dependencies. I will be spending time on coverage to expand this and fix other related problems (e.g. no win coverage builder yet). jrg On Mon, Aug 3, 2009 at 9:21 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: Does code coverage run browser_tests? It seems that not. --~--~-~--~~~---~--~~ 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: [POSIX] Reworking our child process reaping
Sounds good to me. It's nice living in the future and being able to
rely on things like signalfd!
- Dan
p.s. I wrote a man page of sorts for that wy back in the past,
before it existed:
http://lkml.indiana.edu/hypermail/linux/kernel/0106.3/0404.html
On Wed, Aug 5, 2009 at 12:12 PM, Adam Langleya...@chromium.org wrote:
Our child process reaping is a little bit of a hack right now, which
is my fault. I didn't anticipate how bad it would turn out.
Currently, we use a bunch of hacks to make sure that we reap all the
children that we need to, but don't reap children from another part of
the code etc. If we need to make sure that a process dies within x
seconds, then we fork off a thread etc. process_util_posix.cc is scary
complex and bodgy.
Here's my plan:
We have a singleton object in base which handles all forking and reaping:
class ChildProcessReaper {
public:
// Has the same semantics as fork() - i.e. this function returns twice. In
// the parent process, the resulting child will be reaped on exit and the
// termination state will be saved. It can be accessed using
// GetTerminationState() below.
pid_t ForkAndRetainTerminationState(uint64_t* child_id);
// Same as ForkAndRetainTerminationState, but the child's termination state
// will not be retained on exit.
pid_t ForkAndForget(uint64_t* child_id);
// Get the termination state of a child started with
// ForkAndRetainTerminationState(). If the child has terminated, then ths
// function will return true and *status is set to the value obtained from
// wait(2).
bool GetTerminationState(uint64_t child_id, int* status);
// Wait |seconds| seconds for the given child to terminate. If it doesn't
// terminate within that amount of time, send SIGKILL. Calling this function
// is a no-op if the child has already terminated. If the child was created
// with ForkAndRetainTerminationState, then calling this function means that
// the child's terminate state will no longer be retained.
void EnsureChildTerminates(float seconds, uint64_t child_id);
This object is created in the IO thread of the browser. On Linux it'll
create a signalfd to get SIGCHILD. On OS X it'll spawn off a
PlatformThread which sits in wait(2) for child notifications. We can
then ensure that we'll never get zombies.
The only wrinkle is that we need to return both a pid_t and another id
(uint64_t above). Consider the following situation:
1) Thread A forks off a child, pid $x
2) The child runs, terminates and is reaped
3) Thread B forks off a child. Because $x has been reaped the kernel
is free to reuse that pid
Now, both thread A and B can call EnsureChildTerminates with pid $x
and kill the wrong child.
Any thoughts?
AGL
--~--~-~--~~~---~--~~
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: code coverage and browser_tests
Sure! For Mac and Linux I expect things will be fine no matter what you throw in. jrg On Wed, Aug 5, 2009 at 12:43 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: Thanks. Can I just try adding browser_tests to the list and send you a CL if it works? On Tue, Aug 4, 2009 at 11:33, John Grabowski j...@chromium.org wrote: No. You can find the list of unittest files run by coverage in chrome.gyp; look at the end of chrome.gyp for the coverage target and list of dependencies. I will be spending time on coverage to expand this and fix other related problems (e.g. no win coverage builder yet). jrg On Mon, Aug 3, 2009 at 9:21 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Does code coverage run browser_tests? It seems that not. --~--~-~--~~~---~--~~ 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: code coverage and browser_tests
I don't think Mac passes browser_test, I believe it hangs. I opened a bug on this a little while ago: http://crbug.com/16322 TVL On Wed, Aug 5, 2009 at 3:49 PM, John Grabowski j...@chromium.org wrote: Sure! For Mac and Linux I expect things will be fine no matter what you throw in. jrg On Wed, Aug 5, 2009 at 12:43 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Thanks. Can I just try adding browser_tests to the list and send you a CL if it works? On Tue, Aug 4, 2009 at 11:33, John Grabowski j...@chromium.org wrote: No. You can find the list of unittest files run by coverage in chrome.gyp; look at the end of chrome.gyp for the coverage target and list of dependencies. I will be spending time on coverage to expand this and fix other related problems (e.g. no win coverage builder yet). jrg On Mon, Aug 3, 2009 at 9:21 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Does code coverage run browser_tests? It seems that not. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Trick question: Who is responsible for repairing a red tree?
If that was not enough of a trick question: Suppose you checkin with 5 other people at the same time, and the tree goes red as a consequence of that group's landing, but you are sure you didn't break the tree. Are YOU responsible to help fix it? Answer: *YES*, you are responsible. For me, all too often (surely more than once) I've been dead sure, absolutely sure, positively sure, it was not me but it WAS me. When the tree goes red, it is the responsibility of ALL persons that committed in that group to repair the tree, or to talk to each other *and* the sheriff. It is not the sheriff's job to revert The sheriff is the fallback, when for good or bad reasons engineers drop the ball, and shirk their responsibility. If you're part of a group that adds color to the tree, and you don't *offer* to revert, and explain (and convince other's) that it wasn't you, then you are adding to the pile up. Not talking, explaining, and hanging around ends up causing other folks (including clueless sheriffs like me) to spend a lot of time evaluating your patch vs the others in your group. By not talking, by not watching, by not helping to clear the redness, an engineer makes the repair take longer. (...and of course, makes it ... er... um less pleasant to be a sheriff). If you don't have enough time to hang out, and wait till the FULL impact (not just compilation) is seen in the tree, then get a buddy (or someone on IRC?) to take help you fulfill your responsibility, or just wait till later to land. Please fly and land responsibly. Thanks, Jim (today's sheriff... but hopefully speaking of behalf of all sheriffs) --~--~-~--~~~---~--~~ 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: Trick question: Who is responsible for repairing a red tree?
I agree.. reading this as someone slated for duty tomorrow got me thinking about one pseudo-related question / point. I know lots of time people cram stuff into the tree status to explain who is working on which red bit, and what tests are flaky today and we (sheriffs or someone watching the tree) shouldn't immediately freak out and shut things down for. That doesn't scale so well when there are several things going on. And sometimes it isn't written anywhere, so you have to ask on IRC. That's fine, but it presents a race condition if you're not in the channel at the right time so you have to keep asking, unless you're always on IRC and can cleverly search the window contents. A constant place to go looking for this would make it easier, at least in my opinion. Like right now I don't know what's up with Chromium Mac (valgrind) or Webkit dbg (12) to name a few; they're red but the tree is open. The only thing that comes to mind at the moment is a spreadsheet or something we can easily jot down and track currently known problem areas. A real-time tactical plan of sorts, to help sheriffs and anyone else that's interested. We could link to / embed this with a hover-over or something on the waterfall. Maybe that is too much overhead. There's possibly a more usable way to do this, I haven't given it much thought. Has anyone else thought about this in the past? On Wed, Aug 5, 2009 at 1:31 PM, Jim Roskind j...@chromium.org wrote: If that was not enough of a trick question: Suppose you checkin with 5 other people at the same time, and the tree goes red as a consequence of that group's landing, but you are sure you didn't break the tree. Are YOU responsible to help fix it? Answer: *YES*, you are responsible. For me, all too often (surely more than once) I've been dead sure, absolutely sure, positively sure, it was not me but it WAS me. When the tree goes red, it is the responsibility of ALL persons that committed in that group to repair the tree, or to talk to each other *and* the sheriff. It is not the sheriff's job to revert The sheriff is the fallback, when for good or bad reasons engineers drop the ball, and shirk their responsibility. If you're part of a group that adds color to the tree, and you don't *offer* to revert, and explain (and convince other's) that it wasn't you, then you are adding to the pile up. Not talking, explaining, and hanging around ends up causing other folks (including clueless sheriffs like me) to spend a lot of time evaluating your patch vs the others in your group. By not talking, by not watching, by not helping to clear the redness, an engineer makes the repair take longer. (...and of course, makes it ... er... um less pleasant to be a sheriff). If you don't have enough time to hang out, and wait till the FULL impact (not just compilation) is seen in the tree, then get a buddy (or someone on IRC?) to take help you fulfill your responsibility, or just wait till later to land. Please fly and land responsibly. Thanks, Jim (today's sheriff... but hopefully speaking of behalf of all sheriffs) --~--~-~--~~~---~--~~ 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: Trick question: Who is responsible for repairing a red tree?
On Wed, Aug 5, 2009 at 2:45 PM, Tim Steelet...@chromium.org wrote: you have to keep asking, unless you're always on IRC and can cleverly search the window contents. A constant place to go looking for this would make it easier, at least in my opinion. Like right now I don't know what's up with Chromium Mac (valgrind) You need to be on IRC and scroll back: [13:55] dkegelmac valgrind unit - rohitrao? [13:57] motownavi dkegel: very likely [13:58] dkegelemailed rohit [14:02] rohitrao dkegel, jar: looking [14:30] rohitrao jar, dkegel: reverted 22517 I doubt anything more durable than IRC is going to help... IRC and the tree status are the place to go, I'm afraid. --~--~-~--~~~---~--~~ 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: Trick question: Who is responsible for repairing a red tree?
On Wed, Aug 5, 2009 at 2:45 PM, Tim Steele t...@chromium.org wrote: A constant place to go looking for this would make it easier, at least in my opinion. Like right now I don't know what's up with Chromium Mac (valgrind) or Webkit dbg (12) to name a few; they're red but the tree is open. If you ever see a case like this, go ahead and close the tree yourself until you get an explanation for every bit of redness. Then put the explanation into the tree status. I know people hate having the tree closed, but we need to be hard-nosed about closing it for _anything_ red. 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: Trick question: Who is responsible for repairing a red tree?
On Wed, Aug 5, 2009 at 2:49 PM, Peter Kastingpkast...@google.com wrote: Like right now I don't know what's up with Chromium Mac (valgrind) or Webkit dbg (12) to name a few; they're red but the tree is open. If you ever see a case like this, go ahead and close the tree yourself until you get an explanation for every bit of redness. Then put the explanation into the tree status. I know people hate having the tree closed, but we need to be hard-nosed about closing it for _anything_ red. Yeah. And don't be afraid to press people to immediately revert if you think that'd make the tree green. --~--~-~--~~~---~--~~ 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: Trick question: Who is responsible for repairing a red tree?
On Wed, Aug 5, 2009 at 2:49 PM, Peter Kasting pkast...@google.com wrote: On Wed, Aug 5, 2009 at 2:45 PM, Tim Steele t...@chromium.org wrote: A constant place to go looking for this would make it easier, at least in my opinion. Like right now I don't know what's up with Chromium Mac (valgrind) or Webkit dbg (12) to name a few; they're red but the tree is open. If you ever see a case like this, go ahead and close the tree yourself until you get an explanation for every bit of redness. Then put the explanation into the tree status. I know people hate having the tree closed, but we need to be hard-nosed about closing it for _anything_ red. This is the approach I default to, because I'm just pessimistic by nature :) I think the one time I closed the tree in the last 5 months was one of these cases, and I was scolded because it wasn't necessary, so in true Pavlovian fashion I'm now afraid to do it again. Nevertheless, dually noted! Maybe just a way to have a bit more verbose tree status? A details link that would just expand below the status header to show the rest of the text? I'll tell you what, I'll build up a bit more experience as a sheriff myself before I start making grand plans to redesign things :) 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: Trick question: Who is responsible for repairing a red tree?
Very much agreed. If anything is red, and it's not immediately clear that someone's on it, close the tree. The burden should be on whoever is explaining why the tree is open but red, not why it's closed, especially for the sheriff. --Amanda On Wednesday, August 5, 2009, Peter Kasting pkast...@google.com wrote: On Wed, Aug 5, 2009 at 2:45 PM, Tim Steele t...@chromium.org wrote: A constant place to go looking for this would make it easier, at least in my opinion. Like right now I don't know what's up with Chromium Mac (valgrind) or Webkit dbg (12) to name a few; they're red but the tree is open. If you ever see a case like this, go ahead and close the tree yourself until you get an explanation for every bit of redness. Then put the explanation into the tree status. I know people hate having the tree closed, but we need to be hard-nosed about closing it for _anything_ red. PK -- Portability is generally the result of advance planning rather than trench warfare involving #ifdef -- Henry Spencer (1992) --~--~-~--~~~---~--~~ 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: Trick question: Who is responsible for repairing a red tree?
One thing the mozilla waterfall has (or did have at one time) is the ability to add comments to any build column/step. I've seen it used so someone can hang a quick comment of reverting or ### pushed with fix. That way right next to a specific problem you can have any extra info, and unlike irc, it's there if you come looking after it's been said. Does it make sense to support something like that? TVL On Wed, Aug 5, 2009 at 5:55 PM, Tim Steele t...@chromium.org wrote: On Wed, Aug 5, 2009 at 2:49 PM, Peter Kasting pkast...@google.com wrote: On Wed, Aug 5, 2009 at 2:45 PM, Tim Steele t...@chromium.org wrote: A constant place to go looking for this would make it easier, at least in my opinion. Like right now I don't know what's up with Chromium Mac (valgrind) or Webkit dbg (12) to name a few; they're red but the tree is open. If you ever see a case like this, go ahead and close the tree yourself until you get an explanation for every bit of redness. Then put the explanation into the tree status. I know people hate having the tree closed, but we need to be hard-nosed about closing it for _anything_ red. This is the approach I default to, because I'm just pessimistic by nature :) I think the one time I closed the tree in the last 5 months was one of these cases, and I was scolded because it wasn't necessary, so in true Pavlovian fashion I'm now afraid to do it again. Nevertheless, dually noted! Maybe just a way to have a bit more verbose tree status? A details link that would just expand below the status header to show the rest of the text? I'll tell you what, I'll build up a bit more experience as a sheriff myself before I start making grand plans to redesign things :) 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] desktop notifications, preliminary code for review
Hi all, I'm still waiting for my WebKit patch which creates the Desktop Notification API to be reviewed and get checked in, but since it may yet be a while I posted some of the chromium-side code at http://codereview.appspot.com/104044/. As I mentioned to some of you offline, I would greatly appreciate a pre-review so I can start to work out the issues and be as ready as possible to check in once the WebKit process finishes. This isn't the entire set of changes but contains the core pieces that would most benefit from feedback. Worker integration, e.g., will follow up in a separate patch. This is my first time through with most of these tools, so let me know if I can do anything to make it easier. A design doc that gives an overview of how this stuff works is attached to this email. Feedback is welcome on that too. Thanks, -John --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~--- Notifications in Chromium Design Doc.rtf Description: RTF file
[chromium-dev] Re: desktop notifications, preliminary code for review
On Wed, Aug 5, 2009 at 3:51 PM, John Greggjohn...@google.com wrote: As I mentioned to some of you offline, I would greatly appreciate a pre-review so I can start to work out the issues and be as ready as possible to check in once the WebKit process finishes. Looks promising, but I see Mac and Windows code and no Linux. ? --~--~-~--~~~---~--~~ 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: desktop notifications, preliminary code for review
On Wed, Aug 5, 2009 at 4:00 PM, Evan Martine...@chromium.org wrote: On Wed, Aug 5, 2009 at 3:51 PM, John Greggjohn...@google.com wrote: As I mentioned to some of you offline, I would greatly appreciate a pre-review so I can start to work out the issues and be as ready as possible to check in once the WebKit process finishes. Looks promising, but I see Mac and Windows code and no Linux. ? To clarify, I'd at least like to see the design doc address how and whether this will work on Linux. For example, suppose the APIs available were more broad -- maybe then there is extra information that ought to be plumbed around. --~--~-~--~~~---~--~~ 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: desktop notifications, preliminary code for review
On Linux you could probably get this effect by using the notify-send utility: http://manpages.ubuntu.com/manpages/gutsy/man1/notify-send.1.html http://www.galago-project.org/specs/notification/0.9/index.html --Mike On Wed, Aug 5, 2009 at 4:00 PM, Evan Martine...@chromium.org wrote: On Wed, Aug 5, 2009 at 3:51 PM, John Greggjohn...@google.com wrote: As I mentioned to some of you offline, I would greatly appreciate a pre-review so I can start to work out the issues and be as ready as possible to check in once the WebKit process finishes. Looks promising, but I see Mac and Windows code and no Linux. ? --~--~-~--~~~---~--~~ 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: desktop notifications, preliminary code for review
Has a design doc for this feature in general been sent around? This is a fairly large change otherwise. -Ben On Wed, Aug 5, 2009 at 4:13 PM, Evan Martine...@chromium.org wrote: On Wed, Aug 5, 2009 at 4:00 PM, Evan Martine...@chromium.org wrote: On Wed, Aug 5, 2009 at 3:51 PM, John Greggjohn...@google.com wrote: As I mentioned to some of you offline, I would greatly appreciate a pre-review so I can start to work out the issues and be as ready as possible to check in once the WebKit process finishes. Looks promising, but I see Mac and Windows code and no Linux. ? To clarify, I'd at least like to see the design doc address how and whether this will work on Linux. For example, suppose the APIs available were more broad -- maybe then there is extra information that ought to be plumbed around. --~--~-~--~~~---~--~~ 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 Mac Chrome in release mode
Startup of Chrome in gdb after a rebuild is now 10 seconds faster! Excellent! jrg On Wed, Aug 5, 2009 at 12:32 PM, Mark Mentovai m...@chromium.org wrote: I just checked in r22506, which alters the structure of the application on disk on the Mac slightly. The entire program has moved into a dylib (framework) that lives within the app bundle, and the main executable is now a tiny stub that doesn't do anything but jump to the entry point in the dylib. I've got more related changes in the oven, but that's another story... The only noticeable change now from a development perspective is that gdb won't be able to find debugging symbols for the dylib when you're working in release mode. gdb looks for a dSYM bundle next to the framework, but we don't copy the dSYM into the app bundle (because we don't want it there). In case you need to debug a release-mode bundle, you'll need to place a symlink: cd xcodebuild ln -fs ../../../Chromium\ Framework.framework.dSYM Release/Chromium.app/Contents/Frameworks/ Then, when you debug Chromium.app: gdb Release/Chromium.app it will be able to load the framework's debugging symbols. I haven't used the Xcode debugger in a while, but the same symlink should work to get you on track there as well, since the Xcode debugger is just a gdb front-end. Mark --~--~-~--~~~---~--~~ 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: desktop notifications, preliminary code for review
The plan for linux is to use libnotify, which is Growl-like, for text notifications, and possibly something we build for HTML balloon notifications which could be turned on or off by the user. Can you elaborate on what you mean by more broad? We think that offering a text version and an html version which app writers can query for in the browser allow us to offer on each platform the most full-featured option that makes sense to those users. Other user agents could then implement one or the other or both as makes sense for their platforms (thinking mobile especially). I'll update the doc to discuss the linux plan. -John On Wed, Aug 5, 2009 at 4:13 PM, Evan Martin e...@chromium.org wrote: On Wed, Aug 5, 2009 at 4:00 PM, Evan Martine...@chromium.org wrote: On Wed, Aug 5, 2009 at 3:51 PM, John Greggjohn...@google.com wrote: As I mentioned to some of you offline, I would greatly appreciate a pre-review so I can start to work out the issues and be as ready as possible to check in once the WebKit process finishes. Looks promising, but I see Mac and Windows code and no Linux. ? To clarify, I'd at least like to see the design doc address how and whether this will work on Linux. For example, suppose the APIs available were more broad -- maybe then there is extra information that ought to be plumbed around. --~--~-~--~~~---~--~~ 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: desktop notifications, preliminary code for review
Sorry, maybe not. It's a big world to keep up to date! Between WHATWG, webkit-dev, and offline it's been discussed at some length at many levels, but not much on this list as I check the archives. But in any case, while the code patch is large as I said I consider it preliminary, and this is why I ask for feedback on the document (and the design expressed in it) as well as the code. Thanks, -John On Wed, Aug 5, 2009 at 4:29 PM, Ben Goodger (Google) b...@chromium.orgwrote: Has a design doc for this feature in general been sent around? This is a fairly large change otherwise. -Ben On Wed, Aug 5, 2009 at 4:13 PM, Evan Martine...@chromium.org wrote: On Wed, Aug 5, 2009 at 4:00 PM, Evan Martine...@chromium.org wrote: On Wed, Aug 5, 2009 at 3:51 PM, John Greggjohn...@google.com wrote: As I mentioned to some of you offline, I would greatly appreciate a pre-review so I can start to work out the issues and be as ready as possible to check in once the WebKit process finishes. Looks promising, but I see Mac and Windows code and no Linux. ? To clarify, I'd at least like to see the design doc address how and whether this will work on Linux. For example, suppose the APIs available were more broad -- maybe then there is extra information that ought to be plumbed around. --~--~-~--~~~---~--~~ 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: desktop notifications, preliminary code for review
Is there any reason you're doing this on appspot's code review, not chromium's? I reviewed half the patch at a high level. I think there's plenty of comments to address for now. Once those are addressed, I'm happy to take a deeper dive with the rest if there aren't any more qualified reviewers who'd like to take it on. Even though this has been discussed to death, it might be good to still write up a mini-design doc since that's easier than code to review and I'm sure there's plenty of people who'd like to sanity check the design. (That said, I didn't see any major design flaws while reviewing.) J On Wed, Aug 5, 2009 at 4:52 PM, John Gregg john...@google.com wrote: Sorry, maybe not. It's a big world to keep up to date! Between WHATWG, webkit-dev, and offline it's been discussed at some length at many levels, but not much on this list as I check the archives. But in any case, while the code patch is large as I said I consider it preliminary, and this is why I ask for feedback on the document (and the design expressed in it) as well as the code. Thanks, -John On Wed, Aug 5, 2009 at 4:29 PM, Ben Goodger (Google) b...@chromium.orgwrote: Has a design doc for this feature in general been sent around? This is a fairly large change otherwise. -Ben On Wed, Aug 5, 2009 at 4:13 PM, Evan Martine...@chromium.org wrote: On Wed, Aug 5, 2009 at 4:00 PM, Evan Martine...@chromium.org wrote: On Wed, Aug 5, 2009 at 3:51 PM, John Greggjohn...@google.com wrote: As I mentioned to some of you offline, I would greatly appreciate a pre-review so I can start to work out the issues and be as ready as possible to check in once the WebKit process finishes. Looks promising, but I see Mac and Windows code and no Linux. ? To clarify, I'd at least like to see the design doc address how and whether this will work on Linux. For example, suppose the APIs available were more broad -- maybe then there is extra information that ought to be plumbed around. --~--~-~--~~~---~--~~ 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: desktop notifications, preliminary code for review
Yes. Major feature work should have a design doc sent to chromium-dev. Please write one up in the design docs section of dev.chromium.org. -Ben On Wed, Aug 5, 2009 at 5:03 PM, Jeremy Orlowjor...@chromium.org wrote: Is there any reason you're doing this on appspot's code review, not chromium's? I reviewed half the patch at a high level. I think there's plenty of comments to address for now. Once those are addressed, I'm happy to take a deeper dive with the rest if there aren't any more qualified reviewers who'd like to take it on. Even though this has been discussed to death, it might be good to still write up a mini-design doc since that's easier than code to review and I'm sure there's plenty of people who'd like to sanity check the design. (That said, I didn't see any major design flaws while reviewing.) J On Wed, Aug 5, 2009 at 4:52 PM, John Gregg john...@google.com wrote: Sorry, maybe not. It's a big world to keep up to date! Between WHATWG, webkit-dev, and offline it's been discussed at some length at many levels, but not much on this list as I check the archives. But in any case, while the code patch is large as I said I consider it preliminary, and this is why I ask for feedback on the document (and the design expressed in it) as well as the code. Thanks, -John On Wed, Aug 5, 2009 at 4:29 PM, Ben Goodger (Google) b...@chromium.org wrote: Has a design doc for this feature in general been sent around? This is a fairly large change otherwise. -Ben On Wed, Aug 5, 2009 at 4:13 PM, Evan Martine...@chromium.org wrote: On Wed, Aug 5, 2009 at 4:00 PM, Evan Martine...@chromium.org wrote: On Wed, Aug 5, 2009 at 3:51 PM, John Greggjohn...@google.com wrote: As I mentioned to some of you offline, I would greatly appreciate a pre-review so I can start to work out the issues and be as ready as possible to check in once the WebKit process finishes. Looks promising, but I see Mac and Windows code and no Linux. ? To clarify, I'd at least like to see the design doc address how and whether this will work on Linux. For example, suppose the APIs available were more broad -- maybe then there is extra information that ought to be plumbed around. --~--~-~--~~~---~--~~ 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: Enabled isolation for content scripts
Adam, speaking of garbage collection and content scripts, have you seen http://crbug.com/17410? On Sun, Aug 2, 2009 at 2:17 AM, Adam Barth aba...@chromium.org wrote: On Sun, Aug 2, 2009 at 2:12 AM, dwhdawag...@gmail.com wrote: I believe as a side-effect of this, content scripts can no longer at all access frames in pages (window.frames is a single frame, rather than a collection of them all)... I view this decidedly as a bug rather than feature, and cannot see a reason to intentionally do this (if we can access the DOM of the page, why not also of sub-pages?) Could this be looked at and fixed? Yes. This is a known issue (although I'm not sure if there is a bug on file for it). I haven't quite figured out the right way to do this yet because it involves some tricky garbage collection issues. Rest assured that it will get fixed in due course. If you run into other issues, please let me know. Thanks, 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: Enabled isolation for content scripts
Nope, but I've cc'ed myself. Listening to the channel should keep script alive. Adam On Wed, Aug 5, 2009 at 5:14 PM, Antony Sargentasarg...@google.com wrote: Adam, speaking of garbage collection and content scripts, have you seen http://crbug.com/17410? On Sun, Aug 2, 2009 at 2:17 AM, Adam Barth aba...@chromium.org wrote: On Sun, Aug 2, 2009 at 2:12 AM, dwhdawag...@gmail.com wrote: I believe as a side-effect of this, content scripts can no longer at all access frames in pages (window.frames is a single frame, rather than a collection of them all)... I view this decidedly as a bug rather than feature, and cannot see a reason to intentionally do this (if we can access the DOM of the page, why not also of sub-pages?) Could this be looked at and fixed? Yes. This is a known issue (although I'm not sure if there is a bug on file for it). I haven't quite figured out the right way to do this yet because it involves some tricky garbage collection issues. Rest assured that it will get fixed in due course. If you run into other issues, please let me know. Thanks, 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: fighting the flakiness - resource bundle issues?
On Wed, Aug 5, 2009 at 5:32 PM, Jeremy Orlow jor...@google.com wrote: Which kind soul ended up working on this? Big thanks are in order, but I wanted to let you know that at least one case slipped through the cracks: http://src.chromium.org/viewvc/chrome?view=revrevision=22556 required a clobber today. Any ideas why? It didn't require a clobber; it went green on the next run (inexplicably). 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] PSA: irc awareness [Was: Trick question: Who is responsible for repairing a red tree?]
Most irc clients have an option to beep, flash or shutdown your computer when your nick is mentioned on a channel. It may not be enabled by default so please enable this. Ask around if you can't find how to enable this. Thanks, M-A On Wed, Aug 5, 2009 at 5:48 PM, Dan Kegel d...@kegel.com wrote: On Wed, Aug 5, 2009 at 2:45 PM, Tim Steelet...@chromium.org wrote: you have to keep asking, unless you're always on IRC and can cleverly search the window contents. A constant place to go looking for this would make it easier, at least in my opinion. Like right now I don't know what's up with Chromium Mac (valgrind) You need to be on IRC and scroll back: [13:55] dkegelmac valgrind unit - rohitrao? [13:57] motownavi dkegel: very likely [13:58] dkegelemailed rohit [14:02] rohitrao dkegel, jar: looking [14:30] rohitrao jar, dkegel: reverted 22517 I doubt anything more durable than IRC is going to help... IRC and the tree status are the place to go, I'm afraid. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Buildbot email addresses change
Our buildbot will change of email addresses when it'll restart next time. (It has multiple personalities) So don't be surprised if your outlook filters don't work anymore next time you break the tree or you run a try job. Note that the addresses will now be real and you CAN reply to the emails for help. Hint: you'll likely hit my inbox. :) It is also possible that the buildbot just doesn't restart anymore, M-A --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] gcl change that you should be aware of
Howdy, Quick little change to gcl that everyone should be aware of. When you execute the script it will now automatically pull all physically modified files into the Paths in this changelist section, which means no more copying and pasting the files you changed into your CL. The behavior is closer to that of P4 (where we delete files as opposed to adding them). All the unchanged files are still below. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: Urgent, a very evil site i think which does evil things (no joke)
On Wed, Aug 5, 2009 at 6:03 PM, cpu c...@chromium.org wrote: On Aug 4, 3:36 pm, nakro yoav.zilberb...@gmail.com wrote: Ian, i have a lot of respect to you chrome devs, but i could never figure why you don't just punch holes in the sandbox when Flash or Java or maybe even Reader work In general because sandboxing code that you don't have the source code and can update at any time is asking for trouble. There are several things that are hard to open holes to for flash, for example its own self update. In addition, I think the holes you'd have to open would make it very easy for someone to break out of the sandbox. Of course, most exploits not specifically targeted at Chromium would be foiledso there still is some benefit. J --~--~-~--~~~---~--~~ 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: PSA: irc awareness [Was: Trick question: Who is responsible for repairing a red tree?]
I would love to enable that feature ... anyone know how to do that for Adium on the Mac (IRC support is new in the 1.4 beta)? Failing that, Colloquy? -- Dirk On Wed, Aug 5, 2009 at 5:48 PM, Marc-Antoine Ruelmar...@chromium.org wrote: Most irc clients have an option to beep, flash or shutdown your computer when your nick is mentioned on a channel. It may not be enabled by default so please enable this. Ask around if you can't find how to enable this. Thanks, M-A On Wed, Aug 5, 2009 at 5:48 PM, Dan Kegel d...@kegel.com wrote: On Wed, Aug 5, 2009 at 2:45 PM, Tim Steelet...@chromium.org wrote: you have to keep asking, unless you're always on IRC and can cleverly search the window contents. A constant place to go looking for this would make it easier, at least in my opinion. Like right now I don't know what's up with Chromium Mac (valgrind) You need to be on IRC and scroll back: [13:55] dkegel mac valgrind unit - rohitrao? [13:57] motownavi dkegel: very likely [13:58] dkegel emailed rohit [14:02] rohitrao dkegel, jar: looking [14:30] rohitrao jar, dkegel: reverted 22517 I doubt anything more durable than IRC is going to help... IRC and the tree status are the place to go, I'm afraid. --~--~-~--~~~---~--~~ 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: PSA: irc awareness [Was: Trick question: Who is responsible for repairing a red tree?]
On Colloquy (+ Growl), I set the toast with my name mentioned to never expire. So it's always there unless I X it out. :DG On Wed, Aug 5, 2009 at 7:25 PM, Dirk Prankedpra...@google.com wrote: I would love to enable that feature ... anyone know how to do that for Adium on the Mac (IRC support is new in the 1.4 beta)? Failing that, Colloquy? -- Dirk On Wed, Aug 5, 2009 at 5:48 PM, Marc-Antoine Ruelmar...@chromium.org wrote: Most irc clients have an option to beep, flash or shutdown your computer when your nick is mentioned on a channel. It may not be enabled by default so please enable this. Ask around if you can't find how to enable this. Thanks, M-A On Wed, Aug 5, 2009 at 5:48 PM, Dan Kegel d...@kegel.com wrote: On Wed, Aug 5, 2009 at 2:45 PM, Tim Steelet...@chromium.org wrote: you have to keep asking, unless you're always on IRC and can cleverly search the window contents. A constant place to go looking for this would make it easier, at least in my opinion. Like right now I don't know what's up with Chromium Mac (valgrind) You need to be on IRC and scroll back: [13:55] dkegel mac valgrind unit - rohitrao? [13:57] motownavi dkegel: very likely [13:58] dkegel emailed rohit [14:02] rohitrao dkegel, jar: looking [14:30] rohitrao jar, dkegel: reverted 22517 I doubt anything more durable than IRC is going to help... IRC and the tree status are the place to go, I'm afraid. --~--~-~--~~~---~--~~ 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: PSA: irc awareness [Was: Trick question: Who is responsible for repairing a red tree?]
I use Irssi so I do this: /set bell_beeps ON/set beep_msg_level HILIGHT When I used Mirc, I did this: Options Sounds Enable event beepsOptions IRC Highlight add your name and trigger sound -- Mohamed Mansour On Wed, Aug 5, 2009 at 10:32 PM, Dimitri Glazkov dglaz...@google.comwrote: On Colloquy (+ Growl), I set the toast with my name mentioned to never expire. So it's always there unless I X it out. :DG On Wed, Aug 5, 2009 at 7:25 PM, Dirk Prankedpra...@google.com wrote: I would love to enable that feature ... anyone know how to do that for Adium on the Mac (IRC support is new in the 1.4 beta)? Failing that, Colloquy? -- Dirk On Wed, Aug 5, 2009 at 5:48 PM, Marc-Antoine Ruelmar...@chromium.org wrote: Most irc clients have an option to beep, flash or shutdown your computer when your nick is mentioned on a channel. It may not be enabled by default so please enable this. Ask around if you can't find how to enable this. Thanks, M-A On Wed, Aug 5, 2009 at 5:48 PM, Dan Kegel d...@kegel.com wrote: On Wed, Aug 5, 2009 at 2:45 PM, Tim Steelet...@chromium.org wrote: you have to keep asking, unless you're always on IRC and can cleverly search the window contents. A constant place to go looking for this would make it easier, at least in my opinion. Like right now I don't know what's up with Chromium Mac (valgrind) You need to be on IRC and scroll back: [13:55] dkegelmac valgrind unit - rohitrao? [13:57] motownavi dkegel: very likely [13:58] dkegelemailed rohit [14:02] rohitrao dkegel, jar: looking [14:30] rohitrao jar, dkegel: reverted 22517 I doubt anything more durable than IRC is going to help... IRC and the tree status are the place to go, I'm afraid. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Need some help with Grit
I'm trying to use Grit to compile the theme resource headers for reference. But when I do so, it seems to be counting the includes under if expr=os == 'linux2' though it's not exporting them to the header. For example from compile app_resources.grd: #define IDR_MINIMIZE_H 10581 #define IDR_MINIMIZE_P 10582 #define IDR_FRAME 10595 #define IDR_FRAME_INACTIVE 10596 That's the output, which as you can see, the increment breaks between IDR_MINIMIZE_P and IDR_FRAME. Checking the -x verbose output, it is in fact enumerating the inputs under the linux check there, incrementing the ID value. This doesn't seem to be the same as when you guys build the .rc file though, as the correct ID for IDR_FRAME is 10583. Is there a command line argument to Grit to step over ifs that evaluate false that I'm missing here? I looked over the source for Grit and your build files as best I could without knowing Python and having never used VC++, but can't find anything related. If nothing else I guess I can just parse them out entirely in my bat..though I really would rather not. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Beware of any issues linking to trucountme.com
A friendly person appears to be spamming our issue tracker w/ a virus link. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: [Chrome-team] Beware of any issues linking to trucountme.com
Sadly there's about 60 of these, still cleaning them up. AFAIK there's no way for me to ban the user :( (Also, queuing up 60 tabs reminds me that I would really love a tab overflow solution :) 2009/8/5 Anthony LaForge lafo...@google.com A friendly person appears to be spamming our issue tracker w/ a virus link. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Flakiness. Please help.
THIS MAIL APPLIES TO YOU Flakiness is growing. Smash it before it gets bigger, and keep it smashed. *** The MOST IMPORTANT section in this gigantic mail: PLEASE spend some of every workday (or each week at least, if you can't spare time each day) looking at test failures, flakiness, valgrind/purify/coverity bugs, crashes, and/or memory bugs. Make it a goal to get an average of one line in the test-expectations file removed each day. If you're a Googler, put it on your OKRs (now, not sometime tomorrow). * DON'T wait for someone to assign bugs to you or ask for your help * DON'T wait for a team fixit week (those haven't worked) * DON'T wait for someone else to solve the problems * DON'T wait until after your current project is finished * DON'T wait until you have worked on WebKit HELP, even if it's just a little, even if it's not your core competence. We currently have hundreds upon hundreds of failing or flaky tests. We can dramatically reduce this quickly but ONLY IF YOU HELP. This is an investment not only in the quality of Chrome but in the team's ability to move fast, so help here doesn't just improve the quality of Chrome, but also the derivative of the quality :) (If you do not know how to do anything above and need handholding, e-mail me and I will help you. It's OK to be ignorant.) *** Next, how you should help keep the tree green at all times: * If you ever look at the buildbot and see red, and there's no explanation in the build status, ask what's going on on #chromium. Ping the sheriffs specifically (they're listed in the upper-right corner). If you do not get an answer about ownership within a few minutes, close the tree (if you have the rights to) or ask someone to close it. THE TREE SHOULD NOT BE OPEN WITH RED THAT NO ONE OWNS. Help the sheriffs out with this -- they can't watch every second. Closed trees suck; unowned bustage sucks more. Be hard-nosed. * Yes, even purify, valgrind, and reliability bot redness. If you can't figure out what to do with these, try pinging erikkay for purify issues and huanr for reliability issues. (Not sure who a good general valgrind contact is.) * If you ever look at the buildbot and see orange (unexpected pass), especially in the WebKit LayoutTest bots, ping the WebKit sheriff (the calendar is linked from the top of http://dev.chromium.org/developers/how-tos/webkit-merge-1 ; I don't know whether it's world-readable). If he wasn't aware of it, agree between you on who will deal with it. Orange alone is not reason to close the tree, but it should NOT be ignored. * DON'T IGNORE TESTS BECAUSE THEY WENT GREEN ON THE NEXT CYCLE. If they're really fixed by someone's commit, that should be easy to determine. Otherwise, they're flaky, and we NEED to mark them as such, not just leave them. *** Finally, how to help if the LayoutTest bots are red or orange: (1) Try and determine if the test(s) are consistently passing/failing unexpectedly, or if they're flaky. Make sure you look at all the different bots to see which OSes are affected. (2) Update src/webkit/tools/layout_tests/test-expectations.txt. Look for the test(s) in question. Often, flaky tests will already be in there as failing or flaky for one OS, and need to have more added; or they will be marked flaky (FAIL PASS) and need CRASH added. If they're not there, add a line. (3) Ensure the test(s) have a bug on file. Note the bug on the expectation. (4) If any tests are crashing (flaky or not), they're high-priority and someone needs to triage them. Today, dglazkov was WebKit sheriff and was having me mark these bugs as P1, Mstone-3, owner:dglazkov. I'm not sure whether the Right Thing is to assign them to the WebKit sheriff or still to him (feel free to comment, dglazkov!). Why are these P1? Because until we prove they can't affect Chrome itself, they potentially can, and Chrome crashes are always P1. They affect stability and security both. (5) If you have commit rights, go ahead and TBR test-expectations changes you're confident of. I even suggest using --force if the tree is closed. Updating expectations is like fixing bustage, it helps the tree go green faster and thus is almost always desirable. If you don't have commit rights, send your review to the WebKit sheriff. *** Your reward for reading this far: * At the end of the quarter, I will nominate for a peer bonus every Googler who puts something meaningful about flakiness/test failures/the other stuff above on their OKRs, accomplishes it, and sends me a note pointing that out. * At the end of the quarter, I will nominate for commit access every non-Googler who sends me a pointer to ten patches relating to the above items that they have posted for review, and who doesn't otherwise have some reason why they can't be nominated. If other people want to sweeten the pot somehow, feel free. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com
[chromium-dev] Re: Flakiness. Please help.
Do we have a list of flakey tests? I feel like we used to have one... On Wed, Aug 5, 2009 at 9:44 PM, Peter Kasting pkast...@google.com wrote: THIS MAIL APPLIES TO YOU Flakiness is growing. Smash it before it gets bigger, and keep it smashed. *** The MOST IMPORTANT section in this gigantic mail: PLEASE spend some of every workday (or each week at least, if you can't spare time each day) looking at test failures, flakiness, valgrind/purify/coverity bugs, crashes, and/or memory bugs. Make it a goal to get an average of one line in the test-expectations file removed each day. If you're a Googler, put it on your OKRs (now, not sometime tomorrow). * DON'T wait for someone to assign bugs to you or ask for your help * DON'T wait for a team fixit week (those haven't worked) * DON'T wait for someone else to solve the problems * DON'T wait until after your current project is finished * DON'T wait until you have worked on WebKit HELP, even if it's just a little, even if it's not your core competence. We currently have hundreds upon hundreds of failing or flaky tests. We can dramatically reduce this quickly but ONLY IF YOU HELP. This is an investment not only in the quality of Chrome but in the team's ability to move fast, so help here doesn't just improve the quality of Chrome, but also the derivative of the quality :) (If you do not know how to do anything above and need handholding, e-mail me and I will help you. It's OK to be ignorant.) *** Next, how you should help keep the tree green at all times: * If you ever look at the buildbot and see red, and there's no explanation in the build status, ask what's going on on #chromium. Ping the sheriffs specifically (they're listed in the upper-right corner). If you do not get an answer about ownership within a few minutes, close the tree (if you have the rights to) or ask someone to close it. THE TREE SHOULD NOT BE OPEN WITH RED THAT NO ONE OWNS. Help the sheriffs out with this -- they can't watch every second. Closed trees suck; unowned bustage sucks more. Be hard-nosed. * Yes, even purify, valgrind, and reliability bot redness. If you can't figure out what to do with these, try pinging erikkay for purify issues and huanr for reliability issues. (Not sure who a good general valgrind contact is.) * If you ever look at the buildbot and see orange (unexpected pass), especially in the WebKit LayoutTest bots, ping the WebKit sheriff (the calendar is linked from the top of http://dev.chromium.org/developers/how-tos/webkit-merge-1 ; I don't know whether it's world-readable). If he wasn't aware of it, agree between you on who will deal with it. Orange alone is not reason to close the tree, but it should NOT be ignored. * DON'T IGNORE TESTS BECAUSE THEY WENT GREEN ON THE NEXT CYCLE. If they're really fixed by someone's commit, that should be easy to determine. Otherwise, they're flaky, and we NEED to mark them as such, not just leave them. *** Finally, how to help if the LayoutTest bots are red or orange: (1) Try and determine if the test(s) are consistently passing/failing unexpectedly, or if they're flaky. Make sure you look at all the different bots to see which OSes are affected. (2) Update src/webkit/tools/layout_tests/test-expectations.txt. Look for the test(s) in question. Often, flaky tests will already be in there as failing or flaky for one OS, and need to have more added; or they will be marked flaky (FAIL PASS) and need CRASH added. If they're not there, add a line. (3) Ensure the test(s) have a bug on file. Note the bug on the expectation. (4) If any tests are crashing (flaky or not), they're high-priority and someone needs to triage them. Today, dglazkov was WebKit sheriff and was having me mark these bugs as P1, Mstone-3, owner:dglazkov. I'm not sure whether the Right Thing is to assign them to the WebKit sheriff or still to him (feel free to comment, dglazkov!). Why are these P1? Because until we prove they can't affect Chrome itself, they potentially can, and Chrome crashes are always P1. They affect stability and security both. (5) If you have commit rights, go ahead and TBR test-expectations changes you're confident of. I even suggest using --force if the tree is closed. Updating expectations is like fixing bustage, it helps the tree go green faster and thus is almost always desirable. If you don't have commit rights, send your review to the WebKit sheriff. *** Your reward for reading this far: * At the end of the quarter, I will nominate for a peer bonus every Googler who puts something meaningful about flakiness/test failures/the other stuff above on their OKRs, accomplishes it, and sends me a note pointing that out. * At the end of the quarter, I will nominate for commit access every non-Googler who sends me a pointer to ten patches relating to the above items that they have posted for review, and who doesn't otherwise have
[chromium-dev] Re: Flakiness. Please help.
On Wed, Aug 5, 2009 at 10:10 PM, Eric Seidel esei...@chromium.org wrote: Do we have a list of flakey tests? I feel like we used to have one... Every test in test-expectations.txt marked PASS FAIL or PASS FAIL CRASH or some similar set of multiple expectations is flaky, or at least thought to be so. 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: Flakiness. Please help.
Ojan is working on the tool for the layout tests. First bits are already checked in. :DG On Wed, Aug 5, 2009 at 10:10 PM, Eric Seidelesei...@chromium.org wrote: Do we have a list of flakey tests? I feel like we used to have one... On Wed, Aug 5, 2009 at 9:44 PM, Peter Kasting pkast...@google.com wrote: THIS MAIL APPLIES TO YOU Flakiness is growing. Smash it before it gets bigger, and keep it smashed. *** The MOST IMPORTANT section in this gigantic mail: PLEASE spend some of every workday (or each week at least, if you can't spare time each day) looking at test failures, flakiness, valgrind/purify/coverity bugs, crashes, and/or memory bugs. Make it a goal to get an average of one line in the test-expectations file removed each day. If you're a Googler, put it on your OKRs (now, not sometime tomorrow). * DON'T wait for someone to assign bugs to you or ask for your help * DON'T wait for a team fixit week (those haven't worked) * DON'T wait for someone else to solve the problems * DON'T wait until after your current project is finished * DON'T wait until you have worked on WebKit HELP, even if it's just a little, even if it's not your core competence. We currently have hundreds upon hundreds of failing or flaky tests. We can dramatically reduce this quickly but ONLY IF YOU HELP. This is an investment not only in the quality of Chrome but in the team's ability to move fast, so help here doesn't just improve the quality of Chrome, but also the derivative of the quality :) (If you do not know how to do anything above and need handholding, e-mail me and I will help you. It's OK to be ignorant.) *** Next, how you should help keep the tree green at all times: * If you ever look at the buildbot and see red, and there's no explanation in the build status, ask what's going on on #chromium. Ping the sheriffs specifically (they're listed in the upper-right corner). If you do not get an answer about ownership within a few minutes, close the tree (if you have the rights to) or ask someone to close it. THE TREE SHOULD NOT BE OPEN WITH RED THAT NO ONE OWNS. Help the sheriffs out with this -- they can't watch every second. Closed trees suck; unowned bustage sucks more. Be hard-nosed. * Yes, even purify, valgrind, and reliability bot redness. If you can't figure out what to do with these, try pinging erikkay for purify issues and huanr for reliability issues. (Not sure who a good general valgrind contact is.) * If you ever look at the buildbot and see orange (unexpected pass), especially in the WebKit LayoutTest bots, ping the WebKit sheriff (the calendar is linked from the top of http://dev.chromium.org/developers/how-tos/webkit-merge-1 ; I don't know whether it's world-readable). If he wasn't aware of it, agree between you on who will deal with it. Orange alone is not reason to close the tree, but it should NOT be ignored. * DON'T IGNORE TESTS BECAUSE THEY WENT GREEN ON THE NEXT CYCLE. If they're really fixed by someone's commit, that should be easy to determine. Otherwise, they're flaky, and we NEED to mark them as such, not just leave them. *** Finally, how to help if the LayoutTest bots are red or orange: (1) Try and determine if the test(s) are consistently passing/failing unexpectedly, or if they're flaky. Make sure you look at all the different bots to see which OSes are affected. (2) Update src/webkit/tools/layout_tests/test-expectations.txt. Look for the test(s) in question. Often, flaky tests will already be in there as failing or flaky for one OS, and need to have more added; or they will be marked flaky (FAIL PASS) and need CRASH added. If they're not there, add a line. (3) Ensure the test(s) have a bug on file. Note the bug on the expectation. (4) If any tests are crashing (flaky or not), they're high-priority and someone needs to triage them. Today, dglazkov was WebKit sheriff and was having me mark these bugs as P1, Mstone-3, owner:dglazkov. I'm not sure whether the Right Thing is to assign them to the WebKit sheriff or still to him (feel free to comment, dglazkov!). Why are these P1? Because until we prove they can't affect Chrome itself, they potentially can, and Chrome crashes are always P1. They affect stability and security both. (5) If you have commit rights, go ahead and TBR test-expectations changes you're confident of. I even suggest using --force if the tree is closed. Updating expectations is like fixing bustage, it helps the tree go green faster and thus is almost always desirable. If you don't have commit rights, send your review to the WebKit sheriff. *** Your reward for reading this far: * At the end of the quarter, I will nominate for a peer bonus every Googler who puts something meaningful about flakiness/test failures/the other stuff above on their OKRs, accomplishes it, and sends me a note pointing that out. * At the end of the quarter, I will nominate for commit access
