Mir

Merge lp:~cemil-azizoglu/mir/fix-1661498 into lp:mir

Proposed by Cemil Azizoglu
Status: Merged
Approved by: Chris Halse Rogers
Approved revision: no longer in the source branch.
Merged at revision: 4104
Proposed branch: lp:~cemil-azizoglu/mir/fix-1661498
Merge into: lp:mir
Diff against target: 30 lines (+8/-5)
1 file modified
tests/acceptance-tests/test_new_display_configuration.cpp (+8/-5)
To merge this branch: bzr merge lp:~cemil-azizoglu/mir/fix-1661498
Reviewer Review Type Date Requested Status
Chris Halse Rogers Approve
Daniel van Vugt Approve
Mir CI Bot continuous-integration Approve
Review via email: mp+320565@code.launchpad.net

Commit message

Description of the change

This is due to the DisplayConfiguration being a fake shared_ptr instead of a genuine shared_ptr. Very rarely, but very frequently on a silo, the test finishes and the object backing the fake pointer gets destroyed, while on a different thread, display config information is still tried to be logged off of this pointer.

This can be reproduced locally more regularly by making the test code faster (e.g. comment out the code after apply_config_change_and_wait_for_propagation()).

Indeed in many other tests in this file, a shared pointer is used for the config. So this change makes things more consistent as well.

With this fix, the silo is happy.

To post a comment you must log in.
Revision history for this message
Mir CI Bot (mir-ci-bot) wrote :

PASSED: Continuous integration, rev:4101
https://mir-jenkins.ubuntu.com/job/mir-ci/3207/
Executed test runs:
    SUCCESS: https://mir-jenkins.ubuntu.com/job/build-mir/4311
    SUCCESS: https://mir-jenkins.ubuntu.com/job/build-0-fetch/4398
    SUCCESS: https://mir-jenkins.ubuntu.com/job/build-1-sourcepkg/release=vivid+overlay/4388
    SUCCESS: https://mir-jenkins.ubuntu.com/job/build-1-sourcepkg/release=xenial+overlay/4388
    SUCCESS: https://mir-jenkins.ubuntu.com/job/build-1-sourcepkg/release=zesty/4388
    SUCCESS: https://mir-jenkins.ubuntu.com/job/build-2-binpkg-mir/arch=amd64,compiler=clang,platform=mesa,release=zesty/4343
        deb: https://mir-jenkins.ubuntu.com/job/build-2-binpkg-mir/arch=amd64,compiler=clang,platform=mesa,release=zesty/4343/artifact/output/*zip*/output.zip
    SUCCESS: https://mir-jenkins.ubuntu.com/job/build-2-binpkg-mir/arch=amd64,compiler=gcc,platform=mesa,release=xenial+overlay/4343
        deb: https://mir-jenkins.ubuntu.com/job/build-2-binpkg-mir/arch=amd64,compiler=gcc,platform=mesa,release=xenial+overlay/4343/artifact/output/*zip*/output.zip
    SUCCESS: https://mir-jenkins.ubuntu.com/job/build-2-binpkg-mir/arch=amd64,compiler=gcc,platform=mesa,release=zesty/4343
        deb: https://mir-jenkins.ubuntu.com/job/build-2-binpkg-mir/arch=amd64,compiler=gcc,platform=mesa,release=zesty/4343/artifact/output/*zip*/output.zip
    SUCCESS: https://mir-jenkins.ubuntu.com/job/build-2-binpkg-mir/arch=cross-armhf,compiler=gcc,platform=android,release=vivid+overlay/4343
        deb: https://mir-jenkins.ubuntu.com/job/build-2-binpkg-mir/arch=cross-armhf,compiler=gcc,platform=android,release=vivid+overlay/4343/artifact/output/*zip*/output.zip
    SUCCESS: https://mir-jenkins.ubuntu.com/job/build-2-binpkg-mir/arch=i386,compiler=gcc,platform=android,release=vivid+overlay/4343
        deb: https://mir-jenkins.ubuntu.com/job/build-2-binpkg-mir/arch=i386,compiler=gcc,platform=android,release=vivid+overlay/4343/artifact/output/*zip*/output.zip
    SUCCESS: https://mir-jenkins.ubuntu.com/job/build-2-binpkg-mir/arch=i386,compiler=gcc,platform=mesa,release=xenial+overlay/4343
        deb: https://mir-jenkins.ubuntu.com/job/build-2-binpkg-mir/arch=i386,compiler=gcc,platform=mesa,release=xenial+overlay/4343/artifact/output/*zip*/output.zip

Click here to trigger a rebuild:
https://mir-jenkins.ubuntu.com/job/mir-ci/3207/rebuild

review: Approve (continuous-integration)
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

OK yeah. If we don't have explicit control over our threads then a proper shared_ptr is required.

Although this implies that the shared object should also be doing its own locking to be thread- safe...?

review: Approve
Revision history for this message
Chris Halse Rogers (raof) wrote :

I don't think this implies the object should be doing its own locking - the problem here is that it's being used after destruction. The Display holds locks when accessing the mutable methods on it.

LGTM.

review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'tests/acceptance-tests/test_new_display_configuration.cpp'
2--- tests/acceptance-tests/test_new_display_configuration.cpp 2017-03-14 02:26:28 +0000
3+++ tests/acceptance-tests/test_new_display_configuration.cpp 2017-03-21 22:29:34 +0000
4@@ -475,9 +475,10 @@
5 using namespace testing;
6
7 auto format = GetParam();
8- mtd::StubDisplayConfig single_format_config(1, {format});
9+ auto single_format_config =
10+ std::make_shared<mtd::StubDisplayConfig>(1, std::vector<MirPixelFormat>{format});
11
12- apply_config_change_and_wait_for_propagation(mt::fake_shared(single_format_config));
13+ apply_config_change_and_wait_for_propagation(single_format_config);
14
15 DisplayClient client{new_connection()};
16
17@@ -507,9 +508,11 @@
18 60.0,
19 true,
20 subpixel_arrangement};
21- mtd::StubDisplayConfig single_subpixel_config({output});
22-
23- apply_config_change_and_wait_for_propagation(mt::fake_shared(single_subpixel_config));
24+
25+ auto single_subpixel_config =
26+ std::make_shared<mtd::StubDisplayConfig>(std::vector<mg::DisplayConfigurationOutput>{output});
27+
28+ apply_config_change_and_wait_for_propagation(single_subpixel_config);
29
30 DisplayClient client{new_connection()};
31

Subscribers

People subscribed via source and target branches