Mir

[testsfail] ClientLatency failure under valgrind

Bug #1522031 reported by Kevin DuBois
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mir
Won't Fix
Medium
Daniel van Vugt

Bug Description

Running the ClientLatency test suite under valgrind produces failures, which are not present on non-valgrind runs:

└>>> valgrind --trace-children=yes --leak-check=full --show-leak-kinds=definite --errors-for-leak-kinds=definite --track-fds=yes --num-callers=128 --suppressions=../tools/valgrind_suppressions_generic --suppressions=../tools/valgrind_suppressions_glibc_2.21 bin/mir_acceptance_tests --gtest_filter="ClientLatency*"
==1122== Memcheck, a memory error detector
==1122== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==1122== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==1122== Command: bin/mir_acceptance_tests --gtest_filter=ClientLatency*
==1122==
MIR_CLIENT_PLATFORM_PATH=bin/../lib/client-modules/
MIR_SERVER_PLATFORM_PATH=bin/../lib/server-modules/
LD_LIBRARY_PATH=/usr/local/lib:/usr/lib/debug:bin/../lib
exec=bin/mir_acceptance_tests.bin
==1122== Memcheck, a memory error detector
==1122== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==1122== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==1122== Command: bin/mir_acceptance_tests.bin --gtest_filter=ClientLatency*
==1122==
Running main() from main.cpp
Note: Google Test filter = ClientLatency*
[==========] Running 2 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 2 tests from ClientLatency
[ RUN ] ClientLatency.triple_buffered_client_uses_all_buffers
/home/kdub/source/mir/buffer-semantics/vault-disconnect/tests/acceptance-tests/test_latency.cpp:228: Failure
Value of: observed_latency
Expected: is > 1.9
  Actual: 1.9 (of type float)
[ FAILED ] ClientLatency.triple_buffered_client_uses_all_buffers (10030 ms)
[ RUN ] ClientLatency.throttled_input_rate_yields_lower_latency
/home/kdub/source/mir/buffer-semantics/vault-disconnect/tests/acceptance-tests/test_latency.cpp:259: Failure
Value of: observed_latency
Expected: is < 1.1
  Actual: 1.6 (of type float)
[ FAILED ] ClientLatency.throttled_input_rate_yields_lower_latency (2564 ms)
[----------] 2 tests from ClientLatency (12606 ms total)

[----------] Global test environment tear-down
[==========] 2 tests from 1 test case ran. (12649 ms total)
[ PASSED ] 0 tests.
[ FAILED ] 2 tests, listed below:
[ FAILED ] ClientLatency.triple_buffered_client_uses_all_buffers
[ FAILED ] ClientLatency.throttled_input_rate_yields_lower_latency

Tags: testsfail

Related branches

Revision history for this message
Kevin DuBois (kdub) wrote :

This bug seems to be a tributary of lp: #1505962

Revision history for this message
Kevin DuBois (kdub) wrote :
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Not sure what to do with this bug. The test appears to be correct. It's a real-time multi-process performance test, so as such probably should never be run under Valgrind. Any change to the test itself would probably just weaken it.

Changed in mir:
importance: High → Medium
milestone: 0.19.0 → none
assignee: nobody → Daniel van Vugt (vanvugt)
Changed in mir:
milestone: none → 0.19.0
Changed in mir:
status: New → In Progress
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Won't Fix. But a workaround is on the way.

Failing a performance sensitive test when run in a slow environment is a good thing. We should not hide it, just be aware of it.

Changed in mir:
milestone: 0.19.0 → none
status: In Progress → Won't Fix
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:mir at revision None, scheduled for release in mir, milestone 0.19.0

Changed in mir:
status: Won't Fix → Fix Committed
Changed in mir:
status: Fix Committed → Won't Fix
Revision history for this message
Kevin DuBois (kdub) wrote :

another instance of this failing, (i think even after the workaround): https://jenkins.qa.ubuntu.com/job/mir-xenial-i386-ci/149/consoleFull

Should we have a bug that's causing CI failures that we won't fix? Moved to "Confirmed", so it still gets some visibility/effort

Changed in mir:
status: Won't Fix → Confirmed
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:mir at revision 3192, scheduled for release in mir, milestone 0.19.0

Changed in mir:
status: Confirmed → Fix Committed
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I've already got a separate bug open :)

Changed in mir:
status: Fix Committed → Won't Fix
Revision history for this message
Daniel van Vugt (vanvugt) wrote :
Revision history for this message
Daniel van Vugt (vanvugt) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.