New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 853939 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Document that linking for large binaries can take a while

Project Member Reported by dmu...@chromium.org, Jun 18 2018

Issue description

I followed the steps to calculate coverage on my own checkout, and linking the binary seems to take forever. I've been linking for a couple hours - not much cpu or ram usage by the linker, so I'm not sure what is happening here.

CL:

python tools/code_coverage/coverage.py     content_unittests     -b out/coverage -o out/report     -c 'out/coverage/content_unittests --gtest_filter=SessionStorageContextMojo*'     -f content/browser/dom_storage/
[2018-06-18 14:03:12,529 INFO] Building ['content_unittests'].
ninja: Entering directory `/usr/local/google/home/dmurph/cr-home/src/out/coverage'
[8/9] LINK ./content_unittests

 

Comment 1 by dmu...@chromium.org, Jun 18 2018

Ah! it finished after about 1.5 hours. So maybe this is WAI?

Comment 2 by mmoroz@chromium.org, Jun 18 2018

Summary: Document that linking for large binaries can take a while (was: Linking hangs forever)
Yeah, this is expected for really large targets, e.g. content_unittests. But thanks for the feedback, I think we should add a more explicit note on that to the documentation: https://chromium.googlesource.com/chromium/src/+/master/docs/code_coverage.md

Comment 3 by mmoroz@chromium.org, Jun 22 2018

Status: WontFix (was: Untriaged)
It should be not bad at all after fixing  issue 851337  and  issue 846054 . WontFix.

Sign in to add a comment