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

Issue 731466 link

Starred by 1 user
Status: Assigned
Owner:
erikc...@chromium.org
Cc:
ssid@chromium.org
primiano@chromium.org
█ hjd@chromium.org
█ picksi@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug
Hotlist-MemoryInfra



Sign in to add a comment

ProcessMemoryMetricsEmitter browser tests fail with high probability in debug

Project Member Reported by jchin...@chromium.org, Jun 9 2017 
On debug builds at ToT, FetchAndEmitMetrics and FetchThreeTimes fail with high probability. Release builds at ToT test runs pass reliably. Failures look like:

../../chrome/browser/metrics/process_memory_metrics_emitter_browsertest.cc:78: Failure
Value of: count_matches
  Actual: false
Expected: true
../../chrome/browser/metrics/process_memory_metrics_emitter_browsertest.cc:80: Failure
Expected: (samples->sum()) > (0u), actual: 0 vs 0
Memory.Experimental.Browser2.Malloc
../../chrome/browser/metrics/process_memory_metrics_emitter_browsertest.cc:78: Failure
Value of: count_matches
  Actual: false
Expected: true
../../chrome/browser/metrics/process_memory_metrics_emitter_browsertest.cc:80: Failure
Expected: (samples->sum()) > (0u), actual: 0 vs 0
Memory.Experimental.Browser2.Resident
../../chrome/browser/metrics/process_memory_metrics_emitter_browsertest.cc:78: Failure
Value of: count_matches
  Actual: false
Expected: true
../../chrome/browser/metrics/process_memory_metrics_emitter_browsertest.cc:80: Failure
Expected: (samples->sum()) > (0u), actual: 0 vs 0
Memory.Experimental.Browser2.PrivateMemoryFootprint
[  FAILED  ] ProcessMemoryMetricsEmitterTest.FetchAndEmitMetrics, where TypeParam =  and GetParam() =  (3387 ms)
[----------] 1 test from ProcessMemoryMetricsEmitterTest (3387 ms total)

../../chrome/browser/metrics/process_memory_metrics_emitter_browsertest.cc:78: Failure
Value of: count_matches
  Actual: false
Expected: true
../../chrome/browser/metrics/process_memory_metrics_emitter_browsertest.cc:78: Failure
Value of: count_matches
  Actual: false
Expected: true
../../chrome/browser/metrics/process_memory_metrics_emitter_browsertest.cc:78: Failure
Value of: count_matches
  Actual: false
Expected: true
[  FAILED  ] ProcessMemoryMetricsEmitterTest.FetchThreeTimes, where TypeParam =  and GetParam() =  (3498 ms)
[----------] 1 test from ProcessMemoryMetricsEmitterTest (3498 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (3500 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] ProcessMemoryMetricsEmitterTest.FetchThreeTimes, where TypeParam =  and GetParam() =

Comment 1 by jchin...@chromium.org, Jun 9 2017

Labels: OS-Linux

Comment 2 by erikc...@chromium.org, Jun 9 2017

Cc: primiano@chromium.org
The test in question doesn't appear flaky on flakiness dashboard:
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=FetchAndEmitMetrics

There are Linux swarming failures, but those appear unrelated. Furthermore, the nature of the failure [no browser malloc/resident/footprint] stats suggests that somehow, we're failing to get those stats from the browser process on Linux debug builds.

Comment 3 by primiano@chromium.org, Jun 9 2017

Cc: hjd@chromium.org

Comment 4 by hjd@chromium.org, Jun 9 2017 

hmm, couldn't reproduce on my Linux box at 7e8ca79558fc6b22196c1f82766e12bba3b10f87

I set 'is_debug = true' and tried various combinations of
enable_nacl = true/false
is_component_build = true/false
remove_webcore_debug_symbols = true/false

Built with:
ninja -C out/DesktopDebug browser_tests


And ran:
xvfb-run -s "-screen 0 1024x768x24" ./out/DesktopDebug/browser_tests --test-launcher-bot-mode --gtest_filter="ProcessMemoryMetricsEmitter*" --gtest_repeat=100

Comment 5 by erikc...@chromium.org, Jun 9 2017 

The best way to debug this will be for me to take a look at jchinlee's machine sometime when we're both in the same location. Will do so next week.

Comment 6 by jchin...@chromium.org, Jun 9 2017

Cc: ssid@chromium.org
It looks like this got fixed in the interim at crrev.com/93876304f62aa5f7c2354c739e5ac84e61d3ea13. Can someone with more context confirm? Thanks!

Comment 7 by ssid@chromium.org, Jun 9 2017 

The CL shouldnt change anything. It adds an extra api that is not yet used.

Comment 8 by jchin...@chromium.org, Jun 9 2017 

Hm, you're right. I tried a couple more revisions in the range and now it looks like between r478156 and r478157 the probability of test failures drops substantially.
►

Sign in to add a comment