[chromium-dev] Re: Paper about DRAM error rates
I think it would be an interesting experiment as well. The paper provided a lot of interesting information on DRAM failure rates, but I don't think you can infer failure rates about the general population solely from examining the DRAM failures in a very isolated (though large) population such as Google's data centers. Google data centers introduce unique environmental factors (such as custom mother boards, power supplies, network linking, etc.) which can all affect failure rates. While the correlations drawn between things such as utilization and temperature and failure rate may be applicable, overall failure rate I think is not. -Shane On Oct 7, 12:37 pm, Scott Hess sh...@chromium.org wrote: I think it would be a very interesting experiment, because it would firewall the SQLite code from Chrome memory stompers (which IMHO are a much more likely danger than DRAM errors). -scott --~--~-~--~~~---~--~~ 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: Buildbot upgrade
On Sun, Oct 11, 2009 at 6:41 PM, Anthony LaForge lafo...@google.com wrote: Hey man, this url doesn't seem to be resolving anymore: Ooops. I have a fix and will restart the master in a few minutes. Sorry about that. Nicolas http://chrome-buildbot.corp.google.com:8010/bot_status.json?json=213 Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Sat, Oct 10, 2009 at 6:25 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: Hello, Today I upgraded buildbot to the latest version. If you have a bookmark for the failures only waterfall, you will need to change it. Previously it was failures=1 and it is now show_events=truefailures_only=true Other than that, nothing should have changed. If you see any issues with the new version, please let me know! Thank you, Nicolas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Buildbot upgrade
On Sun, Oct 11, 2009 at 6:50 PM, Thomas Van Lenten thoma...@chromium.orgwrote: Looks like the failures link needs to be updated in waterfall header. I'm pretty sure I did, can you show me which one is not updated? TVL On Sat, Oct 10, 2009 at 9:25 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: Hello, Today I upgraded buildbot to the latest version. If you have a bookmark for the failures only waterfall, you will need to change it. Previously it was failures=1 and it is now show_events=truefailures_only=true Other than that, nothing should have changed. If you see any issues with the new version, please let me know! Thank you, Nicolas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Buildbot upgrade
On Mon, Oct 12, 2009 at 10:45 AM, Nicolas Sylvain nsylv...@chromium.orgwrote: On Sun, Oct 11, 2009 at 6:50 PM, Thomas Van Lenten thoma...@chromium.orgwrote: Looks like the failures link needs to be updated in waterfall header. I'm pretty sure I did, can you show me which one is not updated? http://build.chromium.org/buildbot/waterfall/console, Navigate section in the top left has a failures links. fyi - I updated the Sheriff wiki page on dev.chromium.org. TVL TVL On Sat, Oct 10, 2009 at 9:25 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: Hello, Today I upgraded buildbot to the latest version. If you have a bookmark for the failures only waterfall, you will need to change it. Previously it was failures=1 and it is now show_events=truefailures_only=true Other than that, nothing should have changed. If you see any issues with the new version, please let me know! Thank you, Nicolas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Buildbot upgrade
On Mon, Oct 12, 2009 at 7:58 AM, Thomas Van Lenten thoma...@chromium.orgwrote: On Mon, Oct 12, 2009 at 10:45 AM, Nicolas Sylvain nsylv...@chromium.orgwrote: On Sun, Oct 11, 2009 at 6:50 PM, Thomas Van Lenten thoma...@chromium.org wrote: Looks like the failures link needs to be updated in waterfall header. I'm pretty sure I did, can you show me which one is not updated? http://build.chromium.org/buildbot/waterfall/console, Navigate section in the top left has a failures links. fixed, thanks fyi - I updated the Sheriff wiki page on dev.chromium.org. TVL TVL On Sat, Oct 10, 2009 at 9:25 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: Hello, Today I upgraded buildbot to the latest version. If you have a bookmark for the failures only waterfall, you will need to change it. Previously it was failures=1 and it is now show_events=truefailures_only=true Other than that, nothing should have changed. If you see any issues with the new version, please let me know! Thank you, Nicolas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Who owns crash...@chromium.org and why is there so many updates from it?
Does this relate to receiving crashbot emails adding Crash labels on closed-out bugs where the backtrace doesn't apparently have any relevance to the original backtraces involved with the bug? I've gotten a couple of these in the past week. -scott [Unfortunately, I don't remember the earlier one, the latter is http://crbug.com/13113 ] On Tue, Oct 6, 2009 at 9:58 PM, John Abd-El-Malek j...@chromium.org wrote: On Tue, Oct 6, 2009 at 8:57 PM, Anthony LaForge lafo...@chromium.org wrote: The short of it: People manually associated bugs in http:crash My tool creates its own map of signatures and for whatever reason that bug is on all of them It goes through each aggregate signature and updates the status of the bug (which is a flash crasher) It's made much worse because we are dealing w/ crashes that don't have symbols and cannot be aggregated... What went wrong: The limiting function (seeing if crash-VERSION) was applied does not happen for priority updates. This was actually intentional since we start looking at crash data early on. However this should no longer be needed since we wait for enough data that priority should no longer be shifting. What can be done about it? I will put a limiter on setting the priority Thanks. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Oct 6, 2009 at 8:46 PM, Patrick Johnson patr...@chromium.org wrote: John's question is about why it's generating so many issue updates. Patrick On Tue, Oct 6, 2009 at 8:41 PM, Anthony LaForge lafo...@chromium.org wrote: It's the role account that manages crashes and crash related bugs. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Oct 6, 2009 at 7:26 PM, Patrick Johnson patr...@chromium.org wrote: [+laforge] On Tue, Oct 6, 2009 at 6:51 PM, John Abd-El-Malek j...@chromium.org wrote: I got 21 emails in the last day for http://code.google.com/p/chromium/issues/detail?id=20915 --~--~-~--~~~---~--~~ 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: Who owns crash...@chromium.org and why is there so many updates from it?
I just had crashbot add a totally unrelated stack trace to a bug. I emailed anthony about it, we'll see. Something is clearly wrong. On Mon, Oct 12, 2009 at 12:41 PM, Scott Hess sh...@chromium.org wrote: Does this relate to receiving crashbot emails adding Crash labels on closed-out bugs where the backtrace doesn't apparently have any relevance to the original backtraces involved with the bug? I've gotten a couple of these in the past week. -scott [Unfortunately, I don't remember the earlier one, the latter is http://crbug.com/13113 ] On Tue, Oct 6, 2009 at 9:58 PM, John Abd-El-Malek j...@chromium.org wrote: On Tue, Oct 6, 2009 at 8:57 PM, Anthony LaForge lafo...@chromium.org wrote: The short of it: People manually associated bugs in http:crash My tool creates its own map of signatures and for whatever reason that bug is on all of them It goes through each aggregate signature and updates the status of the bug (which is a flash crasher) It's made much worse because we are dealing w/ crashes that don't have symbols and cannot be aggregated... What went wrong: The limiting function (seeing if crash-VERSION) was applied does not happen for priority updates. This was actually intentional since we start looking at crash data early on. However this should no longer be needed since we wait for enough data that priority should no longer be shifting. What can be done about it? I will put a limiter on setting the priority Thanks. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Oct 6, 2009 at 8:46 PM, Patrick Johnson patr...@chromium.org wrote: John's question is about why it's generating so many issue updates. Patrick On Tue, Oct 6, 2009 at 8:41 PM, Anthony LaForge lafo...@chromium.org wrote: It's the role account that manages crashes and crash related bugs. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Oct 6, 2009 at 7:26 PM, Patrick Johnson patr...@chromium.org wrote: [+laforge] On Tue, Oct 6, 2009 at 6:51 PM, John Abd-El-Malek j...@chromium.org wrote: I got 21 emails in the last day for http://code.google.com/p/chromium/issues/detail?id=20915 -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [linux] dan walsh on a selinux sandbox
On Fedora systems we'll be able to do Real Sandboxing due to SELinux. An SELinux developer took a crack at it: http://danwalsh.livejournal.com/32759.html However, it looks like he's sandboxing our chroot sandbox (?). I don't much understand this stuff, but I think on Fedora we should probably recommend they use the SELinux sandbox directly. It looks like there's an selinux variable set at gyp time. In general, it'd be nice to reach out to Dan since he's likely to know better than anyone here about the right way to do this. I'll link him to this thread from his post. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] dan walsh on a selinux sandbox
On Mon, Oct 12, 2009 at 10:46 AM, Evan Martin e...@chromium.org wrote: In general, it'd be nice to reach out to Dan since he's likely to know better than anyone here about the right way to do this. I'll link him to this thread from his post. I've already emailed him about this, explaining the situation. For anyone finding this thread via a search: use the selinux GYP flag, not Dan's method of building policy for the SUID sandbox. His only suggestion was that we allow the dyntrans type name to be configurable, which seems like a perfectly reasonable thing to do and something that I'll get around to. 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: [linux] GTK 2.18 client-side windows
On Mon, Oct 12, 2009 at 10:53 AM, Adam Langley a...@chromium.org wrote: On Sun, Oct 11, 2009 at 8:39 AM, Evan Martin e...@chromium.org wrote: I think we should to preemptively set the GDK_NATIVE_WINDOWS environment variable mentioned there in our launcher until we've tested it, since this change will surely break us. We use native Xlib calls for the backing store area, obviously, but where else? That page suggests that gdk_x11_drawable_get_xid will make a window native if need be, so that shouldn't be too hard. Unless there's something that I'm missing, I'm not too fearful of this change. Yes, that's more or less what Dan said on the bug I filed about it: http://code.google.com/p/chromium/issues/detail?id=24541 So probably a false alarm. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] GTK 2.18 client-side windows
On Sun, Oct 11, 2009 at 8:39 AM, Evan Martin e...@chromium.org wrote: I think we should to preemptively set the GDK_NATIVE_WINDOWS environment variable mentioned there in our launcher until we've tested it, since this change will surely break us. We use native Xlib calls for the backing store area, obviously, but where else? That page suggests that gdk_x11_drawable_get_xid will make a window native if need be, so that shouldn't be too hard. Unless there's something that I'm missing, I'm not too fearful of this change. 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: Chrome Keyboard Access, opinions?
So, the background story here is as follows: in Windows, the typical toolbar will have one tabstop (accessible through tab or shift-tab) on the whole toolbar, and buttons will then be traversable using left and right arrow keys. For instance, this behavior can be seen in the Quick Launch toolbar, by setting keyboard focus to the Start button, hitting tab, and then arrow through your application shortcuts. Upon gaining keyboard focus, the first button gets hottracked. Our initial solution for the toolbar tried to duplicate this behavior as closely as possible, with a few exceptions. Firstly, my suggestion to add the toolbar to the taborder (accessible by tab or shift-tab, as expected) was vetoed since we did not want to introduce any other tabstop in the UI other than the omnibox and the web content itself. Hence the introduction of a fairly clunky keyboard shortcut to focus the toolbar (ALT+SHIFT+T) came about. If our position on the tabstops have changed, adding a tabstop to the toolbars (and then traverse each button using the arrow keys, once a given toolbar has focus) would best match Windows behavior. Secondly, to further emphasize focus highlighting (beyond hottracking) I also made sure that any existing tooltip would be triggered upon button traversal. Thirdly, we have keyboard shortcuts to access various functionality in the toolbar (F5 for refresh, ALT-keys for the menus, etc). Trying to extend our keyboard access to multiple toolbars (bookmarks, infobars, extensions), I propose the following: 1. Once a toolbar has focus, navigate buttons using the arrow keys, with hottracking and tooltips highlighting which button has focus (consistent with Windows and the behavior we have today in the toolbar). Also keep the current keyboard shortcuts, where a standardized option for such a shortcut exists. 2. The harder problem is to figure out how to focus the first toolbar, and then how to move focus between the toolbars visible. We could take any of a couple of approaches: 1. Add tabstops on the toolbars. 2. Add a mode which when activated will add tabstops to the toolbars. This mode could be entered by a keyboard shortcut, such as ALT+SHIFT+T, and perhaps exited by Esc (or using the mouse to focus anything else in the page). If we support Esc, that should bring focus back to previously focused item, or at least a known, consistent place in the UI. I think that 2.1 is not really feasible, and probably not desirable. I'd place my vote for 2.2, as outlined above (in combination with the maintained characteristics outlined in #1). Hope that makes things a bit clearer, thanks, Jonas On Fri, Oct 9, 2009 at 11:31 AM, Dominic Mazzoni dmazz...@google.comwrote: On Fri, Oct 9, 2009 at 11:15 AM, Jay Campan jcam...@chromium.org wrote: +1. To a beginner, left and right arrow might be more intuitive and an opportunity for us to innovate. But millions of people use screenreaders, have trouble using the mouse, or are just power users who love keyboard shortcuts, and we're just frustrating them by not letting them use standard control navigation keys (like Tab and Shift+Tab) that work throughout Windows. I'll let Jonas comment as I am not sure I remember how we came up with that design. Definitely. BTW, I just joined the accessibility team and I'm hoping to help continue much of the great work Jonas has done so far. He's thought about this a lot more than I have so far, though! 2. In addition, when any control in the toolbar gains focus via the keyboard (or maybe always), the whole toolbar highlights in some subtle way indicating the whole toolbar is the containing region to the focused control. This enables the user to press left and right arrow keys as an additional way to move the focus to other controls in the toolbar - this is similar to how when you have a radio button active, you can use arrows to change the selected radio button. However, if at any point they press Tab or Shift+Tab, they'll navigate among all controls, on or off the toolbar, exactly as one would expect. I see your point with the radio-buttons, but I am not entirely convinced it would be good for the toolbar. With radio buttons, using the arrows is the only way to focus another button (when tab traversing only the selected radio-buttons of a group gets focused). Agreed. Personally I would prefer just supporting Tab and Shift+Tab, plus some extra shortcuts to jump to one or more controls - but I think there's a lot of room for innovation and compromise as long as Tab navigation isn't broken. - Dominic --~--~-~--~~~---~--~~ 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: Buildbot upgrade
Nacl/O3d*trybots seem ok on a restart.-BradN On Mon, Oct 12, 2009 at 8:07 AM, Nicolas Sylvain nsylv...@chromium.orgwrote: On Mon, Oct 12, 2009 at 7:58 AM, Thomas Van Lenten thoma...@chromium.orgwrote: On Mon, Oct 12, 2009 at 10:45 AM, Nicolas Sylvain nsylv...@chromium.orgwrote: On Sun, Oct 11, 2009 at 6:50 PM, Thomas Van Lenten thoma...@chromium.org wrote: Looks like the failures link needs to be updated in waterfall header. I'm pretty sure I did, can you show me which one is not updated? http://build.chromium.org/buildbot/waterfall/console, Navigate section in the top left has a failures links. fixed, thanks fyi - I updated the Sheriff wiki page on dev.chromium.org. TVL TVL On Sat, Oct 10, 2009 at 9:25 PM, Nicolas Sylvain nsylv...@chromium.org wrote: Hello, Today I upgraded buildbot to the latest version. If you have a bookmark for the failures only waterfall, you will need to change it. Previously it was failures=1 and it is now show_events=truefailures_only=true Other than that, nothing should have changed. If you see any issues with the new version, please let me know! Thank you, Nicolas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Please confirm the bug (some bitmaps aren/t displayed)
Please confirm the bug http://code.google.com/p/chromium/issues/detail?id=12900 It really annoys me. I expect that someone will fix it soon. I can provide more examples if needed. --~--~-~--~~~---~--~~ 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: Please confirm the bug (some bitmaps aren/t displayed)
I think the bigger issue is how/when Area-Misc bugs get triaged. Do they ever? If not, we should probably change that. On Mon, Oct 12, 2009 at 11:50 AM, Guria guria...@gmail.com wrote: Please confirm the bug http://code.google.com/p/chromium/issues/detail?id=12900 It really annoys me. I expect that someone will fix it soon. I can provide more examples if needed. --~--~-~--~~~---~--~~ 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: Please confirm the bug (some bitmaps aren/t displayed)
On Mon, Oct 12, 2009 at 20:53, Jeremy Orlow jor...@chromium.org wrote: I think the bigger issue is how/when Area-Misc bugs get triaged. Do they ever? If not, we should probably change that. I sometimes review old bugs and close those which no longer reproduce, and ask for more details in case they're needed (and add FeedbackRequested label). I plan to do another pass like this soon. However, indeed, it would be nice to better triage the bugs. I think we have a lot of forgotten ones in the tracker. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
On Tue, Sep 22, 2009 at 6:06 PM, Dimitri Glazkov dglaz...@google.com wrote: Today wasn't a happy day for p...@. He did a seemingly innocuous roll that broke the world: selenium, ui tests, layout tests. I am sure it was stressful and probably added unnecessary gray to his hair. 2) writers of patches don't test them properly. In Paul's case, it was http://trac.webkit.org/changeset/48639, again by a teammate, and it looks like the patch wasn't very thoroughly tested -- it showed a few regressions in the canary, but because it had to do with V8 garbage collection, the failures were intermittent and seemingly random. However, landing it on trunk looked like a shrapnel blast. Happened again today. Alpha (hclam@) was the most recent victim, along with the prolonged tree closure and sheriff-firefighting. Here's the perp: http://trac.webkit.org/changeset/49429. May I suggest a heaping of WebKit gardening duty as the preventive therapy? :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] inconsistent file_util::CopyDirectory() behavior
Our existing unit tests for file_util::CopyDirectory() do not test its
behavior when the destination directory already exists. The following CL:
http://codereview.chromium.org/271060/show
which adds unit tests for already-existing destination directories, shows
that Windows and POSIX behave differently for recursive copies when the
destination directory already exists. Specifically:
On Windows, a call to file_util::CopyDirectory() with recursive copy enabled
will copy the directory name itself to ay(already-existing) destination
directory. POSIX systems will copy the *contents* of the directory to the
destination. That is, given a 'src' directory containing two files and a
call like:
file_util::CopyDirectory('src', 'existing_dest_dir', true);
On Windows we create 'existing_dest_dir/src/{file1,file2}' while on POSIX we
create just 'existing_dest_dir/{file1,file2}'.
This has come up for memory_test, which uses CopyDirectory() to copy its
checked-in cached user data dir to a freshly-created temporary directory.
At some point the Windows version of memory_test.cc was broken by this
inconsistency. We haven't noticed because the breakage fails to load the
(cached) pages, but still returns memory size data and doesn't cause the
test itself to fail.
Based on the fact that memory_test.cc originally worked on Windows, it seems
like the POSIX behavior is correct/intended (especially since it's
consistent with the behavior when the directory doesn't exist). Any
disagreement? If not, I'll fix Windows accordingly.
--SK
--~--~-~--~~~---~--~~
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: inconsistent file_util::CopyDirectory() behavior
file_util::CopyDirectory is used by Windows installer so we really
need to make sure the change does not break installer.
Huan
On Mon, Oct 12, 2009 at 3:52 PM, Steven Knight s...@chromium.org wrote:
Our existing unit tests for file_util::CopyDirectory() do not test its
behavior when the destination directory already exists. The following CL:
http://codereview.chromium.org/271060/show
which adds unit tests for already-existing destination directories, shows
that Windows and POSIX behave differently for recursive copies when the
destination directory already exists. Specifically:
On Windows, a call to file_util::CopyDirectory() with recursive copy enabled
will copy the directory name itself to ay(already-existing) destination
directory. POSIX systems will copy the *contents* of the directory to the
destination. That is, given a 'src' directory containing two files and a
call like:
file_util::CopyDirectory('src'
, 'existing_dest_dir', true);
On Windows we create 'existing_dest_dir/src/{file1,file2}' while on POSIX we
create just 'existing_dest_dir/{file1,file2}'.
This has come up for memory_test, which uses CopyDirectory() to copy its
checked-in cached user data dir to a freshly-created temporary directory.
At some point the Windows version of memory_test.cc was broken by this
inconsistency. We haven't noticed because the breakage fails to load the
(cached) pages, but still returns memory size data and doesn't cause the
test itself to fail.
Based on the fact that memory_test.cc originally worked on Windows, it seems
like the POSIX behavior is correct/intended (especially since it's
consistent with the behavior when the directory doesn't exist). Any
disagreement? If not, I'll fix Windows accordingly.
--SK
--~--~-~--~~~---~--~~
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: inconsistent file_util::CopyDirectory() behavior
Yes Windows installer relies on this behavior. There are installer_unittests
which might cover this particular use case (in CopyTreeWorkItemTest) but I
am not sure.
On Mon, Oct 12, 2009 at 3:52 PM, Steven Knight s...@chromium.org wrote:
Our existing unit tests for file_util::CopyDirectory() do not test its
behavior when the destination directory already exists. The following CL:
http://codereview.chromium.org/271060/show
which adds unit tests for already-existing destination directories, shows
that Windows and POSIX behave differently for recursive copies when the
destination directory already exists. Specifically:
On Windows, a call to file_util::CopyDirectory() with recursive copy
enabled will copy the directory name itself to ay(already-existing)
destination directory. POSIX systems will copy the *contents* of the
directory to the destination. That is, given a 'src' directory containing
two files and a call like:
file_util::CopyDirectory('src', 'existing_dest_dir', true);
On Windows we create 'existing_dest_dir/src/{file1,file2}' while on POSIX
we create just 'existing_dest_dir/{file1,file2}'.
This has come up for memory_test, which uses CopyDirectory() to copy its
checked-in cached user data dir to a freshly-created temporary directory.
At some point the Windows version of memory_test.cc was broken by this
inconsistency. We haven't noticed because the breakage fails to load the
(cached) pages, but still returns memory size data and doesn't cause the
test itself to fail.
Based on the fact that memory_test.cc originally worked on Windows, it
seems like the POSIX behavior is correct/intended (especially since it's
consistent with the behavior when the directory doesn't exist). Any
disagreement? If not, I'll fix Windows accordingly.
--SK
--~--~-~--~~~---~--~~
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: Scalability
On Wed, Oct 07, 2009 at 06:48:15PM +0200, Craig Schlenter wrote: On Wed, Oct 7, 2009 at 10:00 AM, Craig Schlenter craig.schlen...@gmail.com wrote: [big snip] This problem only seems to happen with the scons shared build. The make build does not have this problem so there seems to be something different about how the dependencies are being generated with the make versus scons gyp backends. I'm now getting build failures for linux_page_load_uitest with the shared object build, under both scons and make: /mnt/sda4/chromium/src/out/Debug/obj/chrome/libbrowser.so: undefined reference to `DevToolsManager::ActivateWindow(RenderViewHost*)' ... and a bunch of other DevToolsManager:: undefined references. (32-bit, Debug. Giving 32-bit Release a spin now.) -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Another case of missing symbols
DBGHELP: c:\windows\symbols\chrome_dll.pdb - file not found DBGHELP: c:\windows\symbols\dll\chrome_dll.pdb - file not found DBGHELP: c:\windows\symbols\symbols\dll\chrome_dll.pdb - file not found SYMSRV: c:\downloads\symbols\chrome_dll.pdb \B4977E8166FE42BCA9DD15A802A2E1D91\chrome_dll.pdb not found SYMSRV: http://msdl.microsoft.com/download/symbols/chrome_dll.pdb/B4977E8166FE42BCA9DD15A802A2E1D91/chrome_dll.pdb not found SYMSRV: c:\downloads\symbols\chrome_dll.pdb \B4977E8166FE42BCA9DD15A802A2E1D91\chrome_dll.pdb not found SYMSRV: http://build.chromium.org/buildbot/symsrv/chrome_dll.pdb/B4977E8166FE42BCA9DD15A802A2E1D91/chrome_dll.pdb not found SYMSRV: c:\downloads\symbols\chrome_dll.pdb \B4977E8166FE42BCA9DD15A802A2E1D91\chrome_dll.pdb not found SYMSRV: http://symbols.mozilla.org/firefox/chrome_dll.pdb/B4977E8166FE42BCA9DD15A802A2E1D91/chrome_dll.pdb not found DBGHELP: C:\Users\bob\AppData\Local\Google\Chrome\Application \3.0.195.25\chrome_dll.pdb - file not found DBGHELP: C:\b\slave\chrome-official-2\build\src\chrome\Release \chrome_dll.pdb - file not found *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Users\bob\AppData\Local\Google\Chrome\Application \3.0.195.25\chrome.dll - DBGHELP: chrome_5fbc - export symbols DBGHELP: c:\windows\symbols\chrome_exe.pdb - file not found DBGHELP: c:\windows\symbols\exe\chrome_exe.pdb - file not found DBGHELP: c:\windows\symbols\symbols\exe\chrome_exe.pdb - file not found SYMSRV: c:\downloads\symbols\chrome_exe.pdb \07625FF3DD114355A283DE97972171AA1\chrome_exe.pdb not found SYMSRV: http://msdl.microsoft.com/download/symbols/chrome_exe.pdb/07625FF3DD114355A283DE97972171AA1/chrome_exe.pdb not found SYMSRV: c:\downloads\symbols\chrome_exe.pdb \07625FF3DD114355A283DE97972171AA1\chrome_exe.pdb not found SYMSRV: http://build.chromium.org/buildbot/symsrv/chrome_exe.pdb/07625FF3DD114355A283DE97972171AA1/chrome_exe.pdb not found SYMSRV: c:\downloads\symbols\chrome_exe.pdb \07625FF3DD114355A283DE97972171AA1\chrome_exe.pdb not found SYMSRV: http://symbols.mozilla.org/firefox/chrome_exe.pdb/07625FF3DD114355A283DE97972171AA1/chrome_exe.pdb not found DBGHELP: C:\Users\bob\AppData\Local\Google\Chrome\Application \chrome_exe.pdb - file not found DBGHELP: C:\b\slave\chrome-official-2\build\src\chrome\Release \chrome_exe.pdb - file not found *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Users\bob\AppData\Local\Google\Chrome\Application \chrome.exe - DBGHELP: chrome - export symbols --~--~-~--~~~---~--~~ 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: Scalability
Maybe you need to clobber? The shared build bot on the FYI waterfall is working: http://build.chromium.org/buildbot/waterfall.fyi/builders/Chromium%20Linux%20Builder%20(dbg-shlib)/builds/1069 On Mon, Oct 12, 2009 at 6:23 PM, Jacob Mandelson ja...@mandelson.org wrote: On Wed, Oct 07, 2009 at 06:48:15PM +0200, Craig Schlenter wrote: On Wed, Oct 7, 2009 at 10:00 AM, Craig Schlenter craig.schlen...@gmail.com wrote: [big snip] This problem only seems to happen with the scons shared build. The make build does not have this problem so there seems to be something different about how the dependencies are being generated with the make versus scons gyp backends. I'm now getting build failures for linux_page_load_uitest with the shared object build, under both scons and make: /mnt/sda4/chromium/src/out/Debug/obj/chrome/libbrowser.so: undefined reference to `DevToolsManager::ActivateWindow(RenderViewHost*)' ... and a bunch of other DevToolsManager:: undefined references. (32-bit, Debug. Giving 32-bit Release a spin now.) -- Jacob --~--~-~--~~~---~--~~ 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: Another case of missing symbols
For version 3.0.195.25, BTW. On Oct 12, 6:25 pm, yuhong yuhongbao_...@hotmail.com wrote: DBGHELP: c:\windows\symbols\chrome_dll.pdb - file not found DBGHELP: c:\windows\symbols\dll\chrome_dll.pdb - file not found DBGHELP: c:\windows\symbols\symbols\dll\chrome_dll.pdb - file not found SYMSRV: c:\downloads\symbols\chrome_dll.pdb \B4977E8166FE42BCA9DD15A802A2E1D91\chrome_dll.pdb not found SYMSRV: http://msdl.microsoft.com/download/symbols/chrome_dll.pdb/B4977E8166F... not found SYMSRV: c:\downloads\symbols\chrome_dll.pdb \B4977E8166FE42BCA9DD15A802A2E1D91\chrome_dll.pdb not found SYMSRV: http://build.chromium.org/buildbot/symsrv/chrome_dll.pdb/B4977E8166FE... not found SYMSRV: c:\downloads\symbols\chrome_dll.pdb \B4977E8166FE42BCA9DD15A802A2E1D91\chrome_dll.pdb not found SYMSRV: http://symbols.mozilla.org/firefox/chrome_dll.pdb/B4977E8166FE42BCA9D... not found DBGHELP: C:\Users\bob\AppData\Local\Google\Chrome\Application \3.0.195.25\chrome_dll.pdb - file not found DBGHELP: C:\b\slave\chrome-official-2\build\src\chrome\Release \chrome_dll.pdb - file not found *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Users\bob\AppData\Local\Google\Chrome\Application \3.0.195.25\chrome.dll - DBGHELP: chrome_5fbc - export symbols DBGHELP: c:\windows\symbols\chrome_exe.pdb - file not found DBGHELP: c:\windows\symbols\exe\chrome_exe.pdb - file not found DBGHELP: c:\windows\symbols\symbols\exe\chrome_exe.pdb - file not found SYMSRV: c:\downloads\symbols\chrome_exe.pdb \07625FF3DD114355A283DE97972171AA1\chrome_exe.pdb not found SYMSRV: http://msdl.microsoft.com/download/symbols/chrome_exe.pdb/07625FF3DD1... not found SYMSRV: c:\downloads\symbols\chrome_exe.pdb \07625FF3DD114355A283DE97972171AA1\chrome_exe.pdb not found SYMSRV: http://build.chromium.org/buildbot/symsrv/chrome_exe.pdb/07625FF3DD11... not found SYMSRV: c:\downloads\symbols\chrome_exe.pdb \07625FF3DD114355A283DE97972171AA1\chrome_exe.pdb not found SYMSRV: http://symbols.mozilla.org/firefox/chrome_exe.pdb/07625FF3DD114355A28... not found DBGHELP: C:\Users\bob\AppData\Local\Google\Chrome\Application \chrome_exe.pdb - file not found DBGHELP: C:\b\slave\chrome-official-2\build\src\chrome\Release \chrome_exe.pdb - file not found *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Users\bob\AppData\Local\Google\Chrome\Application \chrome.exe - DBGHELP: chrome - export symbols --~--~-~--~~~---~--~~ 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: Scalability
On Mon, Oct 12, 2009 at 06:29:02PM -0700, Lei Zhang wrote: Maybe you need to clobber? The shared build bot on the FYI waterfall is working: http://build.chromium.org/buildbot/waterfall.fyi/builders/Chromium%20Linux%20Builder%20(dbg-shlib)/builds/1069 gclient runhooks regenerated a bunch of .mk's, but I'm still getting the same link error. -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
