Re: Xcode hanging, anyone seen this?

Re: Xcode hanging, anyone seen this?

I've seen this on a MacBook Pro (as I said above). Maybe this behavior
is new with the newest XCode though.

On Tue, Nov 30, 2010 at 4:00 PM, Ryosuke Niwa <rniwa <at> google.com> wrote:
> As I said back then, it's probably falling into a deadlock because the
> entire system even I/O stops working and this hard-freeze issue doesn't
> occur on MacBook Pro or a regular MacPro with less number of cores as far as
> I know.
> - Ryosuke
>
> On Tue, Nov 30, 2010 at 3:53 PM, Levi Weintraub <leviw <at> google.com> wrote:
>>
>> It's definitely not a linking bug, as it happened on my Mac Pro
>> immediately when just building WebKit, far before all the compilation had
>> completed, and with nearly no memory consumed (plus it never recovered, even
>> overnight).
>>
>> On Tue, Nov 30, 2010 at 3:41 PM, John Abd-El-Malek
>> <jabdelmalek <at> google.com> wrote:
>>>
>>> It wasn't building WebKit at that point, and I had run the defaults write
>>> thing that limits it to 6 processors.
>>> Thanks for the tip re Spotlight. I will add all these to the wiki now.
>>>
>>> On Tue, Nov 30, 2010 at 2:07 PM, Thomas Van Lenten <thomasvl <at> google.com>
>>> wrote:
>>>>
>>>> Odds are it's linking 6 things that depend on webkit at once and that
>>>> throws the machine into swap hell.  Buy more ram or check the list for some
>>>> of the scripts floating around to limit the number of things that get linked
>>>> at a time.
>>>> TVL
>>>>
>>>> On Tue, Nov 30, 2010 at 5:01 PM, Eric Seidel <eseidel <at> chromium.org>
>>>> wrote:
>>>>>
>>>>> Are you sure that's true?  It certainly didn't in 10.6.0, but it might
>>>>> these days.  Thomas and Mark would know.
>>>>> -eric
>>>>>
>>>>> On Tue, Nov 30, 2010 at 1:47 PM, Ryosuke Niwa <rniwa <at> google.com> wrote:
>>>>>>
>>>>>> You shouldn't enable distcc on SL.  It won't work.
>>>>>> - Ryosuke
>>>>>>
>>>>>> On Tue, Nov 30, 2010 at 11:26 AM, John Abd-El-Malek <jam <at> chromium.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> I recently reimaged my Mac to SL (corp image) and installed
>>>>>>> Xcode 3.2.4.  I ran "defaults write com.apple.Xcode
>>>>>>> PBXNumberOfParallelBuildSubtasks 6" and enabled distributed builds.  Xcode,
>>>>>>> and my whole system, gets hung during compilation.  Anyone else see this?
>>>>>>>
>>>>>>> --
>>>>>>> Chromium Developers mailing list: chromium-dev <at> chromium.org
>>>>>>> View archives, change email options, or unsubscribe:
>>>>>>> http://groups.google.com/a/chromium.org/group/chromium-dev
>>>>>>
>>>>>> --
>>>>>> Chromium Developers mailing list: chromium-dev <at> chromium.org
>>>>>> View archives, change email options, or unsubscribe:
>>>>>> http://groups.google.com/a/chromium.org/group/chromium-dev
>>>>>
>>>>
>>>
>>> --
>>> Chromium Developers mailing list: chromium-dev <at> chromium.org
>>> View archives, change email options, or unsubscribe:
>>> http://groups.google.com/a/chromium.org/group/chromium-dev
>>
>
>
>
> --
> Ryosuke Niwa
> Software Engineer / Chrome WebKit
> Google Inc
>
> --
> Chromium Developers mailing list: chromium-dev <at> chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>

--

-- 
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe: 
    http://groups.google.com/a/chromium.org/group/chromium-dev

Re: Xcode hanging, anyone seen this?

Re: Changing the security model for "chrome" URLs

import trybot results into emacs

I checked in some (not very good) elisp so that in Emacs you can do
the following:
1) right-click the "stdio" link in a Windows trybot email, copy link location
2) M-x trybot RET

And your emacs will then import the Windows trybot results and munge
them into looking enough like local build results such that
compilation-mode will recognize them.  That means you can step through
the error messages using the normal commands and emacs will open the
files locally.

The code lives in tools/emacs, and it's not great but I'm finding it
useful so I figure others might too.  Currently it only knows to
import Windows output onto a non-Windows system but it shouldn't be
too hard to improve.

I added this info to
  http://code.google.com/p/chromium/wiki/Emacs
where we've collected some other Emacs-specific tips.

--

-- 
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe: 
    http://groups.google.com/a/chromium.org/group/chromium-dev

Re: Changing the security model for "chrome" URLs

On Tue, Nov 30, 2010 at 4:04 PM, Zelidrag Hornung <zelidrag <at> chromium.org> wrote:
> inline:
> On Tue, Nov 30, 2010 at 1:01 PM, Adam Barth <abarth <at> chromium.org> wrote:
>> On Tue, Nov 30, 2010 at 11:38 AM, Zelidrag Hornung
>> <zelidrag <at> chromium.org> wrote:
>> > Adam,
>> > I surely welcome change 1), but we have couple of scenarios on ChromeOS
>> > side
>> > that could end up broken:
>> > 2) Cellular modem activation page (chrome://mobilesetup) displays an
>> > iframe
>> > that is hosted from file:/// schema. We might have similar issues with
>> > pages
>> > hosted from partner/OEM partition (i.e. product registration). The same
>> > page
>> > also contains another iframe served from http: schema.
>>
>> I understand that the security considerations for ChromeOS are
>> different, but I'm inclined to say that you should find another
>> solution rather than having an iframe to a file URL.  IMHO, ChromeOS
>> would be better off if it disabled file URLs entirely.
>
> file: schema is already severely limited to only few folders on ChromeOS. We
> won't be able to completely shut it down yet, but eventually I hope that we
> will. We could potentially expose access to the assets though a special data
> source. It would be surely an extra work for us, but what the heck.

That's what we do on other platforms.

>> Iframing an http URL from a chrome URL is almost certainly a bad idea.
>>  What happens if there's a network attacker?  What happens if the
>> frame tries to framebust?  How does the user tell the difference
>> between trusted browser UI and untrusted UI from the network?
>
> The scenarios that we have require interaction between ChromeOS and
> predefined external entities (web sites for google product registration,
> cellular plan activation portal). We need to pass information between the
> browser process and such pages in both directions. This is achieved through
> a wrapper chrome: page that is used as a proxy between such sites and the
> native ChromeOS-specific code in the browser process. Such pages expose a
> predefined API which uses HTML5 messaging to send data:
>
>    browser <---> chrome: wrapper page <---> targeted site
> Such UI surfaces should be wrapped in a non-tab elements (i.e. popup HTML
> dialog), so users won't even see their URLs and would be perceiving them as
> part of ChromeOS not some random web locations.

That's even worse.  If the content framebusts, the attacker gets to
control UI surfaces that look like native browser UI and not like a
web page.

>> > 3) Would we be able to host an http schema based iframe within chrome:
>> > page?
>>
>> You will be able to, but I suspect it's not a good idea.  Why not use
>> CORS instead?  That's much safer because you know that what you
>> receive from the network is just data.
>>
>> > We have couple of places where this is used in ChromeOS right now. These
>> > pages also rely on HTTP5 messaging mechanism functioning between them.
>>
>> What is HTTP5?
>
> I meant to say HTML5 messaging.

Ah.  It seems better to use CORS so that your interaction with
untrusted content is limited to data only.  If we need to show web
content to the user, we should use some sort of UI element with an
address bar (either a tab or a popup window).  That's how the user
knows that this UI comes from the network.

Adam

>> > On Mon, Nov 29, 2010 at 9:28 AM, Adam Barth <abarth <at> chromium.org> wrote:
>> >>
>> >> Hi chromium-dev,
>> >>
>> >> If you don't work on DOMUI in Chrome, please feel free to skip this
>> >> message.
>> >>
>> >> Several folks have asked if we can change the security model for
>> >> "chrome" URLs, such as chrome://newtab/.  Currently, these pages are
>> >> pretty locked-down from a security point of view.  They've effectively
>> >> sandboxed so that an XSS vulnerability in one page cannot spread to
>> >> other DOMUI pages or to the web.  Unfortunately, this tight security
>> >> policy is a headache for folks who author these pages.  As an example,
>> >> the new HTML settings page can't use pushState to create elegant URLs
>> >> in the omnibox because pushState has a security check in it and DOMUI
>> >> pages fail all security checks.
>> >>
>> >> I'm working on a change to adjust the security model of these pages to
>> >> let them use features like pushState while retaining most of the
>> >> mitigations we have now.  If you've authored or plan to author a DOMUI
>> >> page, I'm interested in your feedback on this page to make sure this
>> >> change meets your needs.  Here's the plan:
>> >>
>> >> 1) "chrome" URLs will be able to access other "chrome" URLs that have
>> >> the same "host", much like how http URLs work.  For example,
>> >> chrome://newtab/foo will be able to access chrome://newtab/bar but
>> >> will not be able to access chrome://history/foo.  (Currently, we block
>> >> "chrome" URLs from accessing anything.)
>> >>
>> >> 2) "chrome" URLs will no longer be able to display "file" URLs.
>> >> Currently, chrome://newtab/ can create an iframe to
>> >> file:///etc/passwd.  We originally enabled this feature so that the
>> >> New Tab Page can have hyperlinks to file URLs, but it turns out the
>> >> New Tab Page already needs a fancier way to link to pages to handle
>> >> "about" URLs properly.  Rather than having "about" URLs be a special
>> >> case, we're going to lump "file" URLs and "about" URLs together.
>> >>
>> >> 3) No non-"chrome" URLs will be not be able to display "chrome" URLs.
>> >> We already prevent almost all pages from iframing/linking to "chrome"
>> >> URLs, but we miss a few edge cases.  After this change, we should nail
>> >> all the edge cases.
>> >>
>> >> This design aims to make "chrome" URLs more like regular web URLs.
>> >> The only difference is that "chrome" URLs will have restrictions on
>> >> who can display them (load them in iframes, hyperlink to them, etc).
>> >>
>> >> Let me know if that doesn't work for you.
>> >>
>> >> Thanks!
>> >> Adam
>> >>
>> >> --
>> >> Chromium Developers mailing list: chromium-dev <at> chromium.org
>> >> View archives, change email options, or unsubscribe:
>> >>    http://groups.google.com/a/chromium.org/group/chromium-dev
>> >
>> >
>
>

--

-- 
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe: 
    http://groups.google.com/a/chromium.org/group/chromium-dev

Anyone know the history behind BrowserList::AllBrowsersClosedAndAppExiting()?

Re: Anyone know the history behind BrowserList::AllBrowsersClosedAndAppExiting()?

On Tue, Nov 30, 2010 at 6:09 PM, Drew Wilson <atwilson <at> chromium.org> wrote:
> The problem I ran into with this code is if you are displaying a window, and
> you have cleanup/destructor code that is called *after* this code, this code
> will free your widgets out from underneath you, so when you run your cleanup
> code (say, when a profile exits) you'll end up doing a double-free which can
> be quite difficult to track down. I ran into this when I was working on
> status icons, and now John just ran into it with notifications - it results
> in really fragile behavior, as crashes can linger in the code for quite a
> while until someone actually tries shutting down the app while one of your
> windows is on-screen.
> Anyhow, it seems really fragile for code that doesn't own memory to free
> that memory,

In theory you could write code that went down the same code path as
the user clicking the close button on each window, so it's not exactly
freeing someone else's memory.

> this - does anyone know the history of this code (the move from browser =>
> browser/ui is foiling my novice attempts at using git log).

Try
  git log -M --follow
(That is "with renames" and "follow the log for the files I specified
across renames".)

> I'm wondering if
> there's some way to make this code less fragile, either by removing it, or
> by moving this much later in the shutdown cycle.

Seems to me to be superfluous.  We're shutting down, we should just
quit and let the OS clean up.

--

-- 
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe: 
    http://groups.google.com/a/chromium.org/group/chromium-dev

Re: Xcode hanging, anyone seen this?

Re: Looking for code reviewer for ZLIB library