High CPU usage observed across EDS and indicator-datetime causing clock app tests to fail
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Indicator Date and Time |
Incomplete
|
Undecided
|
Charles Kerr | ||
qtorganizer5-eds (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
We have been observing random clock app test failures in the qa dashboard in image #39 and onwards. On further investigation we were able to reproduce to consistently,
1. Run the clock app tests. You will notice that they pass with the exception of 1 test.
2. Run the calendar app tests now.
3. Run the clock app tests again. Notice that there are about 5-6 test failures related to Alarms (EDS).
Timo noticed high CPU usages of EDS and indicator-datetime after the calendar app test finished. Somehow the calendar app test create events which are then messing up clock app results.
In the QA Dashboard, the clock app test failures are only noticed randomly. This is because the tests are not executed in the same order all the time. So sometimes if the calendar is run after the clock, then the clock app tests have a good time.
Related branches
- Kunal Parmar: Approve
- Ubuntu Phone Apps Jenkins Bot: Approve (continuous-integration)
-
Diff: 336 lines (+105/-49)6 files modifiedtests/autopilot/calendar_app/emulators.py (+61/-0)
tests/autopilot/calendar_app/tests/__init__.py (+9/-1)
tests/autopilot/calendar_app/tests/test_calendar.py (+3/-3)
tests/autopilot/calendar_app/tests/test_dayview.py (+6/-6)
tests/autopilot/calendar_app/tests/test_monthview.py (+10/-10)
tests/autopilot/calendar_app/tests/test_yearview.py (+16/-29)
summary: |
- High CPU usage observed across EDS and indicator-datetime causing tests - clock app tests to fail + High CPU usage observed across EDS and indicator-datetime causing clock + app tests to fail |
description: | updated |
One interesting observation made today though: this happened once during smoketesting, but we didn't notice any failures on system-settle after the calendar-app tests. Normally when the CPU usage is really high (even inbetween reboots) this should have been caught by system settle tests, which generally check if the CPU usage levels don't go crazy. We didn't see those. Any ideas how that could have happened?