lipstick has about 100% cpu load

Question

4

lipstick has about 100% cpu load

bug

asked 2017-10-10 13:18:43 +0300

sistux

161 ●3 ●6 ●14

updated 2017-10-10 15:40:22 +0300

Hello Jolla! I got today the 2.1.2.3 installed. First thing, that I did, was to check the lipstick cpu usage. I looked through forums and, sorry, did not get any tips to get the problem. My device is Jolla phone.

Output of top:

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5791 nemo      20   0  263m 133m  41m S 101.2 16.5  46:44.42 lipstick

And it looks like with the time it has a memory leak

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                
 5791 nemo      20   0  373m 208m  43m S 99.9 25.8 192:14.27 lipstick

Than I found, may it will be useful...

[nemo@Sailfish ~]$ ps -o comm,time -LC lipstick
COMMAND             TIME
lipstick        00:00:17
hwcCommitThr    00:00:00
QEvdevTouchScre 00:00:00
QQmlThread      00:00:06
dconf worker    00:00:00
QDBusConnection 00:00:01
gmain           00:00:00
gdbus           00:00:00
qtaround::mt::A 00:00:00
Qt bearer threa 00:00:00
QQuickXmlQueryE 00:00:00
Qt HTTP thread  00:00:00
GL updater      00:00:03
QSGRenderThread 00:00:13
NemoThumbnailLo 00:00:00
Thread (pooled) 00:48:33
QQuickPixmapRea 00:00:00

Thank you for any advice!

edit retag flag offensive close delete

Comments

My Jolla has always a high CPU usage after the last few updates (not 100% though, more 25-50%). A second reboot always fixes the issue. Did you try that before doing the factory reset? Don't forget to check your btrfs allocation too.

Sthocs ( 2017-10-11 16:29:22 +0300 )edit

Yes, I did more than two reboots. It did not help... The cpu load was observed with "top". After reboot come the tracker-processes for about 15-30 minutes and than the lipstick "eats" one cpu up to 100% alone.

About the btrfs allocation: do you mean the disk usage? I thought, no other brtfs checks are needed up to 60% disk usage... May be the brtfs-check would help. I did not come to idea...

Anyway, Thank you, I did already the reset due to bad battery life - in 4 hours about 30% has gone...

sistux ( 2017-10-11 17:20:21 +0300 )edit

Oh, I was referring to the output of the command btrfs-balancer allocation. Allocation must be lower that 75%. Normally the upgrade triggers an "Optimize" process that does a btrfs balance, but on my device it's not executed since a few updates, so I have to run it manually to avoid the known btrfs issues. (Even if you never pass 60% disk usage, over time the btrfs metadata grow.)

Sthocs ( 2017-10-12 12:42:17 +0300 )edit

ok... but honestly, I can't realise what the brft-allocation (kernel-fs-subsystem) and lipstick (user-space-app) have together?

See the thread in lipstick: Thread (pooled) 00:48:33

sistux ( 2017-10-12 14:48:27 +0300 )edit

Is such behaviour normal?

[nemo@Sailfish ~]$ devel-su btrfs-balancer allocation
Password: 
Total:     14763950080 bytes
Used:      10307921510 bytes
Allocated: 69 %
[nemo@Sailfish ~]$

sistux ( 2017-10-12 14:58:19 +0300 )edit

My Jolla has always a high CPU usage after the last few updates (not 100% though, more 25-50%). A second reboot always fixes the issue. Did you try that before doing the factory reset? Don't forget to check your btrfs allocation too.
Sthocs ( 2017-10-11 16:29:22 +0300 )edit
Yes, I did more than two reboots. It did not help... The cpu load was observed with "top". After reboot come the tracker-processes for about 15-30 minutes and than the lipstick "eats" one cpu up to 100% alone.
About the btrfs allocation: do you mean the disk usage? I thought, no other brtfs checks are needed up to 60% disk usage... May be the brtfs-check would help. I did not come to idea...
Anyway, Thank you, I did already the reset due to bad battery life - in 4 hours about 30% has gone...
sistux ( 2017-10-11 17:20:21 +0300 )edit
Oh, I was referring to the output of the command btrfs-balancer allocation. Allocation must be lower that 75%. Normally the upgrade triggers an "Optimize" process that does a btrfs balance, but on my device it's not executed since a few updates, so I have to run it manually to avoid the known btrfs issues. (Even if you never pass 60% disk usage, over time the btrfs metadata grow.)
Sthocs ( 2017-10-12 12:42:17 +0300 )edit
ok... but honestly, I can't realise what the brft-allocation (kernel-fs-subsystem) and lipstick (user-space-app) have together?
See the thread in lipstick: Thread (pooled) 00:48:33
sistux ( 2017-10-12 14:48:27 +0300 )edit
Is such behaviour normal?
[nemo@Sailfish ~]$ devel-su btrfs-balancer allocation Password: Total: 14763950080 bytes Used: 10307921510 bytes Allocated: 69 % [nemo@Sailfish ~]$
sistux ( 2017-10-12 14:58:19 +0300 )edit

Answer 1

2

answered 2017-10-10 23:17:48 +0300

sistux

161 ●3 ●6 ●14

updated 2017-10-10 23:36:58 +0300

Hello Jolla!

I got it! After more search and trying. Unfortunately, helps only "device factory reset". It happens the second time with me. I know it may be duplicated, but, sorry, I make a note to get a phone to normal state:

Backup your data
Make factory reset
Update firmware
Restore your data

edit flag offensive delete publish link

Comments

Just a note: same issue I had after upgrade from 2.1.2.3 to 2.1.3... After try to "factory reset" I got 2.1.3.7 installed. Now no any problem are seen!!!

sistux ( 2017-11-19 18:42:22 +0300 )edit

I had to do the same. For some time everything was fine lipstick used little CPU, I reinstalled my favourite apps and patches checked the CPU usage, it was normal.. But after some days or weeks (not sure) the problem reappeared. Still have no idea what caused it.

steils ( 2017-12-06 19:12:59 +0300 )edit

Not helped. All the same as above written. After some time 1 cpu core is up to 100% use by lipstick.

[root@Sailfish nemo]# ps -o comm,time -LC lipstick
COMMAND             TIME
lipstick        00:06:56
hwcCommitThr    00:00:00
QEvdevTouchScre 00:00:05
QQmlThread      00:00:06
dconf worker    00:00:00
QDBusConnection 00:01:34
gmain           00:00:00
gdbus           00:00:01
qtaround::mt::A 00:00:59
QThread         00:00:01
Qt bearer threa 00:00:20
QQuickXmlQueryE 00:00:01
Qt HTTP thread  00:00:00
GL updater      00:00:26
QSGRenderThread 00:01:52
QQuickPixmapRea 00:00:02
Qt HTTP thread  00:00:01
Qt HTTP thread  00:00:04
Thread (pooled) 00:24:23
Thread (pooled) 00:00:00

Q-Master ( 2018-03-08 12:17:27 +0300 )edit

I've been interested what's that heavy loaded thread which drains the CPU, so:

  [root@Sailfish applications]# ps -LC lipstick
  PID   LWP TTY          TIME CMD
 6669  6669 ?        00:00:07 lipstick
 6669  6678 ?        00:00:00 hwcCommitThr
 6669  6679 ?        00:00:00 QEvdevTouchScre
 6669  6680 ?        00:00:06 QQmlThread
 6669  6681 ?        00:00:00 dconf worker
 6669  6682 ?        00:00:00 QDBusConnection
 6669  6683 ?        00:00:00 gmain
 6669  6684 ?        00:00:00 gdbus
 6669  6690 ?        00:00:00 qtaround::mt::A
 6669  6841 ?        00:00:00 QThread
 6669  6915 ?        00:00:00 Qt bearer threa
 6669  6925 ?        00:00:00 QQuickXmlQueryE
 6669  6945 ?        00:00:00 Qt HTTP thread
 6669  6969 ?        00:00:00 GL updater
 6669  6970 ?        00:00:02 QSGRenderThread
 6669  6971 ?        00:06:46 Thread (pooled)
 6669  6991 ?        00:00:00 QQuickPixmapRea

It is definitely lipstick's process 6971. I've attached to it

[root@Sailfish applications]# gdb --pid 6971
0x40b1e5e4 in ?? () from /usr/lib/libsqlite3.so.0
(gdb) bt
#0  0x40b1e5e4 in ?? () from /usr/lib/libsqlite3.so.0
#1  0x40b25edc in ?? () from /usr/lib/libsqlite3.so.0
#2  0x40b266b4 in ?? () from /usr/lib/libsqlite3.so.0
#3  0x40b26790 in ?? () from /usr/lib/libsqlite3.so.0
#4  0x40b2682c in ?? () from /usr/lib/libsqlite3.so.0
#5  0x40b3c24a in ?? () from /usr/lib/libsqlite3.so.0
#6  0x40b42f04 in sqlite3_step () from /usr/lib/libsqlite3.so.0
#7  0x406a05d4 in ?? () from /usr/lib/qt5/plugins/sqldrivers/libqsqlite.so
#8  0x406a05d4 in ?? () from /usr/lib/qt5/plugins/sqldrivers/libqsqlite.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Seems that the problem in continuous reading of some sqlite dbs. without debuginfo it is rather hard to understang what dbs are affected. So that's the answer why the bug reappeared.

Q-Master ( 2018-04-17 00:31:53 +0300 )edit

Hey... It is back. the lipstik takes again 100% of CPU... I confirm it...

But I got it working... Just for info: if you make the backup and restore, and phone restart -> the lipstick gets up to 1% May be this info would be usefull !!!

sistux ( 2018-05-06 21:05:46 +0300 )edit

Answer 2

0

answered 2018-03-08 12:19:58 +0300

Q-Master
111 ●3 ●6 ●9

It there any yet progress in this bug? Latest 2.1.4.14 is affected too.

edit flag offensive delete publish link

Comments

1

Hi! If you did not see my comment before. After sometime it is back: the lipstik takes again 100% of CPU... I confirm it...

But I got it working as follow: if you make the backup and then makes restore to this backup, after the phone restart -> the lipstick gets up to 1% May be this info would be useful to you!!!

BUT!!! after two days it comes again!

sistux ( 2018-05-10 00:03:58 +0300 )edit

Accepted Answer

0

answered 2018-03-08 12:41:28 +0300

sistux

161 ●3 ●6 ●14

Hello Jolla!

Yesterday I updated my phone Jolla1 from 2.1.3.X to 2.1.4.14. It looks very nice!

After restart the tracker took some time to be ready. The accu lost only 8 percent of load through the last 10 hours (phone was not in use). For my phone it is done.

Thanks!

edit flag offensive delete publish link

Comments

In my experience, this is just temporary. Can you confirm?

objectifnul ( 2018-03-08 13:58:25 +0300 )edit

If you mean the tracker - it is ok, Or I confirm it.

sistux ( 2018-03-08 14:06:50 +0300 )edit

after upgrade nothing changed for me. 100% cpu usage by lipstick

Q-Master ( 2018-03-13 21:32:16 +0300 )edit

lipstick has about 100% cpu load

Comments

3 Answers

Comments

Comments

Comments

Question tools

Stats

Related questions

lipstick has about 100% cpu load

Comments

3 Answers

Comments

Comments

Comments

Question tools

Public thread

Stats

Related questions