REPRODUCIBILITY: 3 tests out of 3
BUILD ID = OS VERSION (Settings > About product): 3.4.0.22
HARDWARE (Jolla1, Tablet, XA2,…): Xperia X Compact
UI LANGUAGE: Finnish
REGRESSION: (compared to previous public release: Yes, No, ?): Yes
DESCRIPTION:
Voicecall-ui stays constanly at 1.2 to 2.2 % CPU usage on the background.
This type of issue has happened with some earlier releases when something has been changed in the phone UI.
PRECONDITIONS:
No preconditions (any will do)
STEPS TO REPRODUCE:
Put the Sailfish device on the table, screen off.
Call to SailfishOS device using other phone.
Pick up the phone and answer to call.
After the call has been ended make sure the phone app is closed in UX and check the CPU usage using top command.
EXPECTED RESULT:
Voicecall-ui process is present but dormant.
ACTUAL RESULT:
Voicecall-ui is not dormant and uses 1.2 to 2.2 percent CPU constantly.
ADDITIONAL INFORMATION:
Previous similar bug happened with prefetch process of voicecall-ui after reboots, but you only needed to open up the phone app and then close it again, and that would fix assumed race condition.
This time only way to make voicecall-ui dormant again is to kill it from the command line and then open up the phone app once (to make it resident in the memory and operate faster in case of incoming calls).
Same still happens on 4.3.0.12 on my XA2. It has a noticeable impact on battery life. I’m not sure if it always happens after having done a voice call. Restarting lipstick via the SFOS Utilities brings things back to normal.
I ran an strace, wrapped in time, for about 2 minutes when it happened. The phone was idle, display off, connected via SSH. The PID of offending voicecall-ui process was 20171 at that time.
[root@XperiaXA2 defaultuser]# time strace -p 20171 -c
strace: Process 20171 attached
^Cstrace: Process 20171 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.74 0.145000 103 1399 7 poll
31.55 0.100000 17 5600 clock_gettime
22.71 0.072000 25 2800 2800 recvmsg
0.00 0.000000 0 8 restart_syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.317000 32 9807 2807 total
Command terminated by signal 2
real 1m 49.97s
user 0m 0.21s
sys 0m 1.02s
That are quite a lot syscall for an idle process, which, I guess, keeps at least one CPU constantly awake. After restarting the homescreen using Utilities, none of the voicecall-ui processes had a CPU usage of more than 0.0% according to htop.
And to follow up on this, lipstick itself also suffers this problem from time to time. The trigger is unknown. Result of strace -c for lipstick:
[root@XperiaXA2 defaultuser]# time strace -p 20613 -c
strace: Process 20613 attached
^Cstrace: Process 20613 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
78.88 0.351000 206 1702 7 poll
16.18 0.072000 10 6789 clock_gettime
4.72 0.021000 12 1703 epoll_wait
0.22 0.001000 125 8 restart_syscall
0.00 0.000000 0 6 read
------ ----------- ----------- --------- --------- ----------------
100.00 0.445000 43 10208 7 total
Command terminated by signal 2
real 1m 58.88s
user 0m 0.18s
sys 0m 1.15s
Is this method useless, or does lipstick (and voicecall-ui) indeed do a lot of clock_gettime for some reason? Can anyone confirm? Something else I can try?
Again, a few percent cpu usage on one core might not seem a lot, but it amounts to (I guestimate) 1%-2% battery usage per hour.
I can locally reproduce it on incoming calls. After the call, even when rejecting, a voicecall-ui process consumes CPU for no apparent reason. Only restarting home screen (or rebooting) fixes it. The number I’ve used for testing is present in Contacts, if that matters.
I now really wonder if this problem isn’t much more prevalent, as in, how many people have or complain about bad battery life, which might be caused by these problems? Only now that I actively monitor for it, I can link the cause and effect. I now know that I have to restart home screen after each (incoming) call.
Interesting … I have an XA2 on 4.3 and have often wondered why sometimes, with very similar usage, and at home on stable wifi, why I end some days on 25% or so battery and on others it is well over 50%.
There used to be a problem with dismissed notifications eating CPU. Reason there was a QML Animation that kept running in the background or some such [1].
Now, /usr/share/voicecall-ui-jolla/calling/IncomingCallViewBase.qml has something like this:
which is a very similar “Design Pattern”, and Use Case, to the one from the mentioned problem.
I wonder if commenting out line 42, and maybe even binding a visible property to active can solve the OP issue?
Oh, and should someone look into this, there’s a couple more to look at, and possibly some opportunities to go from a FadeAnimation to a FadeAnimator as recommended in [2]
If it turns out that is indeed a problem that’s quite the can of worms. Applications are full of those opacity: maybe ? 1 : 0; Behavior on opacity { FadeAnimator{} } patterns.
I’m on 4.4.0 now, and the problem still persists. And it’s getting annoying, tbh. And, I wonder if this is what makes people complain about bad battery life, like this thread.
I got my Xperia 10 iii and flashed it to SFOS 4.4. I could not reproduce this as easily as it did by the time of creation of the original issue.
EDIT:
Oh well, I only had to make few calls in both directions and end calls, and the issue is back. I think it might depend on who makes and who ends the call.
As a workaround, one can configure systemd to restart the service every hour or so. Run systemctl --user edit voicecall-ui-prestart.service and enter
[Service]
RuntimeMaxSec=3600
then run systemctl --user daemon-reload. After this systemctl --user cat voicecall-ui-prestart.service should show both the original unit file and your override.
Of course, if you are on a call at the moment it gets restarted…
It also happens when ignoring the call by just turning the phone upside down.
I have been doing pkill -f voicecall-ui in the terminal after an incoming call for so long it has become a habit and never thought to look for a bug report here! Now that I freshly flashed 4.6.0.15 on my Xperia 10 V and the problem is back immediately, I finally searched the forum.
The workaround by @andreyv seems nice but problematic when you’re in a call. Is there any way to hook it to hanging up/rejecting the call?
and never thought to look for a bug report here! Now that I freshly flashed 4.6.0.15 on my Xperia 10 V and the problem is back immediately, I finally searched the forum.