"fetch chromium" keeps hanging/getting stuck on Windows 7

[Oren Blasberg]

Hi folks,

I'm trying to build on Windows for the first time, so I'm fetching chromium. However the fetch tool just keeps on getting stuck and I can't tell if it's making progress anymore.

My first attempt: I left it running overnight, and it was still saying "Still working on" src/third_party/WebKit. At that point it showed a [timestamp/ of something like 17 hours and counting. So I Ctrl+C'd, and I had to delete the entire src folder which was already downloaded; trying to fetch again yielded an error without deleting it first.

Now my second attempt: I left it running for at least 1.5 hours already, and this time it seems to have stopped incrementing the "Still working on" bit. It's not outputting any more logging. The last output it printed says:

[1:32:37] Still working on:

[1:32:37]   src/buildtools

[1:32:37]   src/third_party/WebKit

Syncing projects:  96% (84/87) src\buildtools\clang_format\script

I open that directory in Windows and it says last modified at 4:09 PM; it's 4:32 PM now.

Is there any way to find out what's going wrong? Is it a known issue? I haven't encountered this on Linux or Mac development, just Windows, and it's extremely productivity-inhibiting.

Thanks,

Oren

[Scott Graham]

It's almost definitely still going, git is pretty slow on Windows. As long as you see "still working on" you probably just want to wait.

Also, confirm that you're not getting terrible I/O due to AV/bit9.

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

[Kunal Bajpai]

It took 6 hrs with fetch & finally I cancelled it. And now with gclient sync it went for 7hrs, so total 13-14 hrs to get the code. BTW I am using OSX.

----------------------------------

[7:04:38] Still working on:

[7:04:38]   src/third_party/WebKit

[Oren Blasberg]

Something like 1-2 hours after I sent the email yesterday, it completed for me. So it seems like the tool is perhaps a bit flaky. :/

[Torne (Richard Coles)]

Unfortunately it's not that the tool is flaky, it's just that cloning the blink/WebKit repository requires a bunch of resources:

1) the server has to prepare a pack for you if it doesn't have an appropriate one cached, which requires a bunch of server resources to be spent on your behalf before it even sends you the first byte over the network.

2) you have to download that pack file, which is almost 5GB these days.

3) your local copy of git has to validate the pack file actually contains the objects requested and spit out an index for them, which requires churning through the extremely long chains of large delta-compressed objects, the total size of which is vast and massively exceeds git's ability to cache them for reuse even though we explicitly configure a much-larger-than-default delta cache size for you in "fetch". This uses a large chunk of ram for the cache, more ram for the objects being processed, and a boatload of CPU time (mostly single threaded it seems too, so multiple cores don't help much/at all), as well as requiring disk IO to reread parts of the pack file if your machine doesn't have enough ram for the delta cache *and* to keep the entire original pack file cached in memory at the same time as everything else.

Plus, as people have noted, the windows version of git is noticeably slower than the *nix versions.

If you configure it to skip the blink/WebKit repo the total process is *far* shorter, but you can't build without that. The main src repository also has this problem but to a much smaller degree. Our repos here are pushing the limits of what git can scale to because of the large breadth and depth of binary file history they contain.

Doing a shallow clone instead is the only real way to make this faster, but as far as I know fetch/gclient don't support that. You could do it by hand if you figured out the right stuff :/

Hopefully when we manage to migrate to git fully for the project we can come up with a way to not include things like the entire history of the blink LayoutTest files, which would massively reduce this issue.

[Primiano Tucci]

> Doing a shallow clone instead is the only real way to make this faster, but as far as I know fetch/gclient don't support that.

Yeah, sadly we have nothing but a bug on that: crbug.com/228996 (I've just updated it)

[Kunal Bajpai]

It has been running for almost 26 hrs in total. Are there any steps
that I can take to accelerate the fetch process? Is it typical to take
this amount of time on OSX?

[Sergiy Byelozyorov]

+infra-dev

"Have you tried turning it off and on again?" works for me. However, it is often hard to judge if a tool is progressing or just hangs. Perhaps we could provide a little more output for the users about what's happening, e.g. something like what you see when you do gclient sync.

[Primiano Tucci]

Actually turns out that airplane flights are pretty boring and, as my illustrious colleagues teach, sometimes it's easier to fix things yourself rather than complaining ;-)

I got the support to fetch --no-history in https://codereview.chromium.org/437903002

If somebody from infra could review it, we could make life of these guys much easier.

With this I was able to fetch chromium (w/o full history) in 40 minutes over a crappy 7M DSL forgotten by the anti-digital divide (welcome back home, I suppose),

downloading at the end 1.5 GB of stuff from GoB instead of 9+ GB.

Kanual, if you have spare time, would you please try to temporarily use these patched depot_tools and see how long does it take for you now?

Essentially what you have to do is:

$ mkdir /tmp/depot

$ git clone --depth=1 https://github.com/primiano/depot_tools.git /tmp/depot

$ export PATH=$PATH:/tmp/depot

$ fetch --no-history chromium --nosvn=True

$ rm -rf /tmp/depot  # You don't want to use these for anything than a test! Keep using the official ones :)

This is what I got from home:

[~/Downloads/chromium]

$ fetch --no-history chromium --nosvn=True

Running: gclient config --spec 'solutions = [{u'"'"'managed'"'"': False, u'"'"'name'"'"': u'"'"'src'"'"', u'"'"'url'"'"': u'"'"'https://chromium.googlesource.com/chromium/src.git'"'"', u'"'"'custom_deps'"'"': {}, u'"'"'deps_file'"'"': u'"'"'.DEPS.git'"'"', u'"'"'safesync_url'"'"': u'"'"''"'"'}]'

Running: gclient sync --no-history

[0:01:00] Still working on:

[0:01:00]   src

....

[0:38:49] Still working on:

[0:38:49]   src/third_party/WebKit/LayoutTests/w3c/csswg-test

[0:38:49]   src/third_party/WebKit/LayoutTests/w3c/web-platform-tests

Syncing projects: 100% (80/80), done.

Profit! :)

[Kunal Bajpai]

Here is what I got. I am attaching the screen log. It says --no-history is an invalid option.

[pING Wang]

I met the same problem!,the error is like this "fatal: unable to access 'https://chromium.googlesource.com/chromium/src.git/': Failed to connect to 2404:6800:4008:c03::52: No route to host",but I ping the demain of "chromium.googlesource.com",I thine maybe it's the git server's problem.

在 2014年7月31日星期四UTC+8上午7时35分26秒，Oren Blasberg写道：

[Victor Costan]

I'm guessing you also have a normal copy of the depot tools installed and on your path. In this case, you should prepend /tmp/depot to your path, instead of appending it.

More precisely, instead of:

export PATH=$PATH:/tmp/depot

do:

export PATH=/tmp/depot:$PATH

Hope this helps,

    Victor

On Sat, Aug 2, 2014 at 1:23 PM, Kunal Bajpai <kunal....@gmail.com> wrote:

Here is what I got. I am attaching the screen log. It says --no-history is an invalid option.

--

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

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.