Revision history [back]

I've noticed, that after several days of phone usage lipstick process starts to contantly use 16% of CPU time. Luckily this happens only when the screen is turned on.

$ ps -FC lipstick
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
nemo       974   913  1 59460 77196   0 Jan21 ?        01:56:51 /usr/bin/lipstick -plugin evdevtouch:/dev/input/event0:rotate=0 -plugin evdevkeyboard:keymap=/usr/share/qt5/keymaps/boston.qmap --systemd

Note consumed CPU for just a week of usage. If I restart lipstick:

systemctl --user restart lipstick

It's CPU returns to normal ~0% in idle (it might burst sometimes when switching apps or scrolling desktop, but in this case it seems normal).

But after a couple of days lipstick "hangs" again. Seems like a bug to me as it is likely drains battery considerably.

I've tried to investigate the case a bit with strace. A couple of threads of long-running lipstick are heavy busy with futex and reading/writing [eventfd] file descriptor.

I've noticed, that after several days of phone usage lipstick process starts to contantly constantly use 16% of CPU time. Luckily this happens only when the screen is turned on.

$ ps -FC lipstick
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
nemo       974   913  1 59460 77196   0 Jan21 ?        01:56:51 /usr/bin/lipstick -plugin evdevtouch:/dev/input/event0:rotate=0 -plugin evdevkeyboard:keymap=/usr/share/qt5/keymaps/boston.qmap --systemd

Note consumed CPU time for just a week of usage. If I restart lipstick:lipstick (attention, following command stops all gui apps):

systemctl --user restart lipstick

It's CPU returns to normal ~0% in idle (it might burst sometimes when switching apps or scrolling desktop, but in this case it seems normal).

But after a couple of days lipstick "hangs" again. Seems like a bug to me as it is likely drains battery considerably.

I've tried to investigate the case a bit with strace. A couple of threads of long-running lipstick are heavy busy with futex and reading/writing [eventfd] file descriptor.

I've noticed, that after several days of phone usage lipstick process starts to constantly use 16% of CPU time. Luckily this happens only when the screen is turned on.

$ ps -FC lipstick
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
nemo       974   913  1 59460 77196   0 Jan21 ?        01:56:51 /usr/bin/lipstick -plugin evdevtouch:/dev/input/event0:rotate=0 -plugin evdevkeyboard:keymap=/usr/share/qt5/keymaps/boston.qmap --systemd

Note consumed CPU time for just a week of usage. If I restart lipstick (attention, following command stops all gui apps):

systemctl --user restart lipstick

It's CPU returns to normal ~0% in idle (it might burst sometimes when switching apps or scrolling desktop, but in this case it seems normal).

But after a couple of days lipstick "hangs" again. Seems like a bug to me as it is likely drains battery considerably.

I've tried to investigate the case a bit with strace. A couple of threads of long-running lipstick are heavy busy with futex and reading/writing [eventfd] file descriptor.

I've noticed, that after several days of phone usage lipstick process starts to constantly use 16% of CPU time. Luckily this happens only when the screen is turned on.

$ ps -FC lipstick
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
nemo       974   913  1 59460 77196   0 Jan21 ?        01:56:51 /usr/bin/lipstick -plugin evdevtouch:/dev/input/event0:rotate=0 -plugin evdevkeyboard:keymap=/usr/share/qt5/keymaps/boston.qmap --systemd

Note consumed CPU time for just a week of usage. If I restart lipstick (attention, following command stops all gui apps):

systemctl --user restart lipstick

It's CPU returns to normal ~0% in idle (it might burst sometimes when switching apps or scrolling desktop, but in this case it seems normal).

But after a couple of days lipstick "hangs" again. Seems like a bug to me as it is likely drains battery considerably.

I've tried to investigate the case a bit with strace. A couple of threads of long-running lipstick are heavy busy with futex and reading/writing [eventfd] file descriptor.

I've noticed, that after several days of phone usage lipstick process starts to constantly use 16% of CPU time. Luckily this happens only when the screen is turned on.

$ ps -FC lipstick
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
nemo       974   913  1 59460 77196   0 Jan21 ?        01:56:51 /usr/bin/lipstick -plugin evdevtouch:/dev/input/event0:rotate=0 -plugin evdevkeyboard:keymap=/usr/share/qt5/keymaps/boston.qmap --systemd

Note consumed CPU time for just a week of usage. If I restart lipstick (attention, following command stops all gui apps):

systemctl --user restart lipstick

It's CPU usage returns to normal ~0% in idle (it might burst sometimes when switching apps or scrolling desktop, but in this case it seems normal).

But after a couple of days lipstick "hangs" again. Seems like a bug to me as it is likely drains battery considerably.

I've tried to investigate the case a bit with strace. A couple of threads of long-running lipstick are heavy busy with futex and reading/writing [eventfd] file descriptor.

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 266164K    writeable/private: 98152K    shared: 46544K

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 206424K    writeable/private: 64396K    shared: 21952K

pmap -d `pgrep ^lipstick$` | tail -1; ps -FC lipstick

I've noticed, that after several days of phone usage lipstick process starts to constantly use 16% of CPU time. Luckily this happens only when the screen is turned on.

$ ps -FC lipstick
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
nemo       974   913  1 59460 77196   0 Jan21 ?        01:56:51 /usr/bin/lipstick -plugin evdevtouch:/dev/input/event0:rotate=0 -plugin evdevkeyboard:keymap=/usr/share/qt5/keymaps/boston.qmap --systemd

Note consumed CPU time for just a week of usage. If I restart lipstick (attention, following command stops all gui apps):

systemctl --user restart lipstick

It's CPU usage returns to normal ~0% in idle (it might burst sometimes when switching apps or scrolling desktop, but in this case it seems normal).

But after a couple of days lipstick "hangs" again. Seems like a bug to me as it is likely drains battery considerably.

I've tried to investigate the case a bit with strace. A couple of threads of long-running lipstick are heavy busy with futex and reading/writing [eventfd] file descriptor.

Update 2015-02-05: I have a strong feeling that lipstick leaks memory over time as well. Here is memory usage for 2.5 days old lipstick process:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 266164K    writeable/private: 98152K    shared: 46544K

And here is memory usage for freshly started lipstick:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 206424K    writeable/private: 64396K    shared: 21952K

"writeable/private" is the most relevant number.

If someone has uptime of lipstick more than a week, please post here output of following command (needs root)

pmap -d `pgrep ^lipstick$` | tail -1; ps -FC lipstick

I've noticed, that after several days of phone usage lipstick process starts to constantly use 16% of CPU time. Luckily this happens only when the screen is turned on.

$ ps -FC lipstick
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
nemo       974   913  1 59460 77196   0 Jan21 ?        01:56:51 /usr/bin/lipstick -plugin evdevtouch:/dev/input/event0:rotate=0 -plugin evdevkeyboard:keymap=/usr/share/qt5/keymaps/boston.qmap --systemd

Note consumed CPU time for just a week of usage. If I restart lipstick (attention, following command stops all gui apps):

systemctl --user restart lipstick

It's CPU usage returns to normal ~0% in idle (it might burst sometimes when switching apps or scrolling desktop, but in this case it seems normal).

But after a couple of days lipstick "hangs" again. Seems like a bug to me as it is likely drains battery considerably.

I've tried to investigate the case a bit with strace. A couple of threads of long-running lipstick are heavy busy with futex and reading/writing [eventfd] file descriptor.

Update 2015-02-05: I have a strong feeling that lipstick leaks memory over time as well. Here is memory usage for 2.5 days old lipstick process:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 266164K    writeable/private: 98152K    shared: 46544K

And here is memory usage for freshly started lipstick:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 206424K    writeable/private: 64396K    shared: 21952K

"writeable/private" is the most relevant number.

If someone has uptime of lipstick more than a week, please post here output of following command (needs root)

pmap -d `pgrep ^lipstick$` | tail -1; ps -FC lipstick

Update 2015-03-07: Looks like my conclusion about memory leak is not correct. Restarting lipstick indeed frees lots os of swap space, but the reason is that upon restarting lipstick lots of other services restarts. And most of memory freeing is caused by restarting aliendalvik.

However, in 1.1.2.16 the problem seems to be even more severe. I've seen 24% constant CPU usage and even more.

I've noticed, that after several days of phone usage lipstick process starts to constantly use 16% of CPU time. Luckily this happens only when the screen is turned on.

$ ps -FC lipstick
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
nemo       974   913  1 59460 77196   0 Jan21 ?        01:56:51 /usr/bin/lipstick -plugin evdevtouch:/dev/input/event0:rotate=0 -plugin evdevkeyboard:keymap=/usr/share/qt5/keymaps/boston.qmap --systemd

Note consumed CPU time for just a week of usage. If I restart lipstick (attention, following command stops all gui apps):

systemctl --user restart lipstick

It's CPU usage returns to normal ~0% in idle (it might burst sometimes when switching apps or scrolling desktop, but in this case it seems normal).

But after a couple of days lipstick "hangs" again. Seems like a bug to me as it is likely drains battery considerably.

I've tried to investigate the case a bit with strace. A couple of threads of long-running lipstick are heavy busy with futex and reading/writing [eventfd] file descriptor.

Update 2015-02-05: I have a strong feeling that lipstick leaks memory over time as well. Here is memory usage for 2.5 days old lipstick process:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 266164K    writeable/private: 98152K    shared: 46544K

And here is memory usage for freshly started lipstick:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 206424K    writeable/private: 64396K    shared: 21952K

"writeable/private" is the most relevant number.

If someone has uptime of lipstick more than a week, please post here output of following command (needs root)

pmap -d `pgrep ^lipstick$` | tail -1; ps -FC lipstick

Update 2015-03-07: Looks like my conclusion about memory leak is not correct. Restarting lipstick indeed frees lots of swap space, but the reason is that upon restarting lipstick lots of other services restarts. And most of memory freeing is caused by restarting aliendalvik.

However, in 1.1.2.16 the problem seems to be even more severe. I've seen 24% constant CPU usage and even more.

I've noticed, that after several days of phone usage lipstick process starts to constantly use 16% of CPU time. Luckily this happens only when the screen is turned on.

$ ps -FC lipstick
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
nemo       974   913  1 59460 77196   0 Jan21 ?        01:56:51 /usr/bin/lipstick -plugin evdevtouch:/dev/input/event0:rotate=0 -plugin evdevkeyboard:keymap=/usr/share/qt5/keymaps/boston.qmap --systemd

Note consumed CPU time for just a week of usage. If I restart lipstick (attention, following command stops all gui apps):

systemctl --user restart lipstick

It's CPU usage returns to normal ~0% in idle (it might burst sometimes when switching apps or scrolling desktop, but in this case it seems normal).

But after a couple of days lipstick "hangs" again. Seems like a bug to me as it is likely drains battery considerably.

I've tried to investigate the case a bit with strace. A couple of threads of long-running lipstick are heavy busy with futex and reading/writing [eventfd] file descriptor.

Update 2015-02-05: I have a strong feeling that lipstick leaks memory over time as well. Here is memory usage for 2.5 days old lipstick process:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 266164K    writeable/private: 98152K    shared: 46544K

And here is memory usage for freshly started lipstick:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 206424K    writeable/private: 64396K    shared: 21952K

"writeable/private" is the most relevant number.

If someone has uptime of lipstick more than a week, please post here output of following command (needs root)

pmap -d `pgrep ^lipstick$` | tail -1; ps -FC lipstick

Update 2015-03-07: Looks like my conclusion about memory leak is not correct. Restarting lipstick indeed frees lots of swap space, but the reason is that upon restarting lipstick lots of other services restarts. And most of memory freeing is caused by restarting aliendalvik.

However, in 1.1.2.16 the problem seems to be even more severe. I've seen 24% constant CPU usage and even more.

Update 2015-03-19: It happened again, lipstick uses ~15% CPU user time and ~9% system time constantly when the screen is turned on (~24% total). Stopping all applications and aliendalvik does not help. Data requested by @chris.adams:

• mcetool - screen on
• journalctl -af (turning screen on while following log)

I have not noticed any difference in journalctl messages and mcetool output before and after restarting lipstick, though CPU usage returned to normal after lipstick restart.

I've noticed, that after several days of phone usage lipstick lipstick process starts to constantly use 16% of CPU time. Luckily this happens only when the screen is turned on.

$ ps -FC lipstick
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
nemo       974   913  1 59460 77196   0 Jan21 ?        01:56:51 /usr/bin/lipstick -plugin evdevtouch:/dev/input/event0:rotate=0 -plugin evdevkeyboard:keymap=/usr/share/qt5/keymaps/boston.qmap --systemd

Note consumed CPU time for just a week of usage. If I restart lipstick (attention, following command stops all gui apps):

systemctl --user restart lipstick

It's CPU usage returns to normal ~0% in idle (it might burst sometimes when switching apps or scrolling desktop, but in this case it seems normal).

But after a couple of days lipstick "hangs" again. Seems like a bug to me as it is likely drains battery considerably.

I've tried to investigate the case a bit with strace. A couple of threads of long-running lipstick are heavy busy with futex and reading/writing [eventfd] file descriptor.

Update 2015-02-05: I have a strong feeling that lipstick leaks memory over time as well. Here is memory usage for 2.5 days old lipstick process:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 266164K    writeable/private: 98152K    shared: 46544K

And here is memory usage for freshly started lipstick:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 206424K    writeable/private: 64396K    shared: 21952K

"writeable/private" is the most relevant number.

If someone has uptime of lipstick more than a week, please post here output of following command (needs root)

pmap -d `pgrep ^lipstick$` | tail -1; ps -FC lipstick

Update 2015-03-07: Looks like my conclusion about memory leak is not correct. Restarting lipstick indeed frees lots of swap space, but the reason is that upon restarting lipstick lots of other services restarts. And most of memory freeing is caused by restarting aliendalvik.

However, in 1.1.2.16 the problem seems to be even more severe. I've seen 24% constant CPU usage and even more.

Update 2015-03-19: It happened again, lipstick uses ~15% CPU user time and ~9% system time constantly when the screen is turned on (~24% total). Stopping all applications and aliendalvik does not help. Data requested by @chris.adams:

• mcetool - screen on
• journalctl -af (turning screen on while following log)

I have not noticed any difference in journalctl messages and mcetool output before and after restarting lipstick, though CPU usage returned to normal after lipstick restart.

I've noticed, that after several days of phone usage lipstick process starts to constantly use 16% of CPU time. Luckily this happens only when the screen is turned on.

$ ps -FC lipstick
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
nemo       974   913  1 59460 77196   0 Jan21 ?        01:56:51 /usr/bin/lipstick -plugin evdevtouch:/dev/input/event0:rotate=0 -plugin evdevkeyboard:keymap=/usr/share/qt5/keymaps/boston.qmap --systemd

Note consumed CPU time for just a week of usage. If I restart lipstick (attention, following command stops all gui apps):

systemctl --user restart lipstick

It's CPU usage returns to normal ~0% in idle (it might burst sometimes when switching apps or scrolling desktop, but in this case it seems normal).

But after a couple of days lipstick "hangs" again. Seems like a bug to me as it is likely drains battery considerably.

I've tried to investigate the case a bit with strace. A couple of threads of long-running lipstick are heavy busy with futex and reading/writing [eventfd] file descriptor.

Update 2015-02-05: I have a strong feeling that lipstick leaks memory over time as well. Here is memory usage for 2.5 days old lipstick process:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 266164K    writeable/private: 98152K    shared: 46544K

And here is memory usage for freshly started lipstick:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 206424K    writeable/private: 64396K    shared: 21952K

"writeable/private" is the most relevant number.

If someone has uptime of lipstick more than a week, please post here output of following command (needs root)

pmap -d `pgrep ^lipstick$` | tail -1; ps -FC lipstick

Update 2015-03-07: Looks like my conclusion about memory leak is not correct. Restarting lipstick indeed frees lots of swap space, but the reason is that upon restarting lipstick lots of other services restarts. And most of memory freeing is caused by restarting aliendalvik.

However, in 1.1.2.16 the problem seems to be even more severe. I've seen 24% constant CPU usage and even more.

Update 2015-03-19: It happened again, lipstick uses ~15% CPU user time and ~9% system time constantly when the screen is turned on (~24% total). Stopping all applications and aliendalvik does not help. Data requested by @chris.adams:

• mcetool - screen on
• journalctl -af (turning screen on while following log)

I have not noticed any difference in journalctl messages and mcetool output before and after restarting lipstick, though CPU usage returned to normal after lipstick restart.

Update 2015-03-26: Sometimes sensord process enters similar state: constantly using ~7% CPU when the screen is turned on and goes idle when the screen is turned off. Sometimes I see both lipstick and sensord on top of top output and sometimes just one of these process are occupied with their strange job. I am not sure though that these situations are related.

$ ps -o comm,time -LC lipstick
COMMAND             TIME
lipstick        00:21:57
hwcCommitThr    00:00:00
QThread         00:00:34
QQmlThread      00:00:06
dconf worker    00:00:00
gdbus           00:00:01
QQuickPixmapRea 00:00:00
GL updater      00:05:36
QSGRenderThread 00:26:07    <----little rascal!
QThread         00:00:00
cor::qt::Actor_ 00:00:36
QQuickXmlQueryE 00:00:00
Qt bearer threa 00:00:07
QThread         00:00:01
Qt HTTP thread  00:00:00
QProcessManager 00:00:00

I've noticed, that after several days of phone usage lipstick process starts to constantly use 16% of CPU time. Luckily this happens only when the screen is turned on.

$ ps -FC lipstick
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
nemo       974   913  1 59460 77196   0 Jan21 ?        01:56:51 /usr/bin/lipstick -plugin evdevtouch:/dev/input/event0:rotate=0 -plugin evdevkeyboard:keymap=/usr/share/qt5/keymaps/boston.qmap --systemd

Note consumed CPU time for just a week of usage. If I restart lipstick (attention, following command stops all gui apps):

systemctl --user restart lipstick

It's CPU usage returns to normal ~0% in idle (it might burst sometimes when switching apps or scrolling desktop, but in this case it seems normal).

But after a couple of days lipstick "hangs" again. Seems like a bug to me as it is likely drains battery considerably.

I've tried to investigate the case a bit with strace. A couple of threads of long-running lipstick are heavy busy with futex and reading/writing [eventfd] file descriptor.

Update 2015-02-05: I have a strong feeling that lipstick leaks memory over time as well. Here is memory usage for 2.5 days old lipstick process:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 266164K    writeable/private: 98152K    shared: 46544K

And here is memory usage for freshly started lipstick:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 206424K    writeable/private: 64396K    shared: 21952K

"writeable/private" is the most relevant number.

If someone has uptime of lipstick more than a week, please post here output of following command (needs root)

pmap -d `pgrep ^lipstick$` | tail -1; ps -FC lipstick

Update 2015-03-07: Looks like my conclusion about memory leak is not correct. Restarting lipstick indeed frees lots of swap space, but the reason is that upon restarting lipstick lots of other services restarts. And most of memory freeing is caused by restarting aliendalvik.

However, in 1.1.2.16 the problem seems to be even more severe. I've seen 24% constant CPU usage and even more.

Update 2015-03-19: It happened again, lipstick uses ~15% CPU user time and ~9% system time constantly when the screen is turned on (~24% total). Stopping all applications and aliendalvik does not help. Data requested by @chris.adams:

• mcetool - screen on
• journalctl -af (turning screen on while following log)

I have not noticed any difference in journalctl messages and mcetool output before and after restarting lipstick, though CPU usage returned to normal after lipstick restart.

Update 2015-03-26: Sometimes sensord process enters similar state: constantly using ~7% CPU when the screen is turned on and goes idle when the screen is turned off. Sometimes I see both lipstick and sensord on top of top output and sometimes just one of these process are occupied with their strange job. I am not sure though that these situations are related.

Update 2015-04-02: @giucam suggested, that it looks like lipstick is busy with rendering. Good guess! top in displaying threads shows, that most of the CPU time is consumed by QSGRenderThread thread.thread. I've checked swithcing between the events view / the launcher / a fullscreened app. It does not affect CPU usage.

$ ps -o comm,time -LC lipstick
COMMAND             TIME
lipstick        00:21:57
hwcCommitThr    00:00:00
QThread         00:00:34
QQmlThread      00:00:06
dconf worker    00:00:00
gdbus           00:00:01
QQuickPixmapRea 00:00:00
GL updater      00:05:36
QSGRenderThread 00:26:07    <----little rascal!
QThread         00:00:00
cor::qt::Actor_ 00:00:36
QQuickXmlQueryE 00:00:00
Qt bearer threa 00:00:07
QThread         00:00:01
Qt HTTP thread  00:00:00
QProcessManager 00:00:00

I've noticed, that after several days of phone usage lipstick process starts to constantly use 16% of CPU time. Luckily this happens only when the screen is turned on.

$ ps -FC lipstick
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
nemo       974   913  1 59460 77196   0 Jan21 ?        01:56:51 /usr/bin/lipstick -plugin evdevtouch:/dev/input/event0:rotate=0 -plugin evdevkeyboard:keymap=/usr/share/qt5/keymaps/boston.qmap --systemd

Note consumed CPU time for just a week of usage. If I restart lipstick (attention, following command stops all gui apps):

systemctl --user restart lipstick

It's CPU usage returns to normal ~0% in idle (it might burst sometimes when switching apps or scrolling desktop, but in this case it seems normal).

But after a couple of days lipstick "hangs" again. Seems like a bug to me as it is likely drains battery considerably.

I've tried to investigate the case a bit with strace. A couple of threads of long-running lipstick are heavy busy with futex and reading/writing [eventfd] file descriptor.

Update 2015-02-05: I have a strong feeling that lipstick leaks memory over time as well. Here is memory usage for 2.5 days old lipstick process:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 266164K    writeable/private: 98152K    shared: 46544K

And here is memory usage for freshly started lipstick:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 206424K    writeable/private: 64396K    shared: 21952K

"writeable/private" is the most relevant number.

If someone has uptime of lipstick more than a week, please post here output of following command (needs root)

pmap -d `pgrep ^lipstick$` | tail -1; ps -FC lipstick

Update 2015-03-07: Looks like my conclusion about memory leak is not correct. Restarting lipstick indeed frees lots of swap space, but the reason is that upon restarting lipstick lots of other services restarts. And most of memory freeing is caused by restarting aliendalvik.

However, in 1.1.2.16 the problem seems to be even more severe. I've seen 24% constant CPU usage and even more.

Update 2015-03-19: It happened again, lipstick uses ~15% CPU user time and ~9% system time constantly when the screen is turned on (~24% total). Stopping all applications and aliendalvik does not help. Data requested by @chris.adams:

• mcetool - screen on
• journalctl -af (turning screen on while following log)

I have not noticed any difference in journalctl messages and mcetool output before and after restarting lipstick, though CPU usage returned to normal after lipstick restart.

Update 2015-03-26: Sometimes sensord process enters similar state: constantly using ~7% CPU when the screen is turned on and goes idle when the screen is turned off. Sometimes I see both lipstick and sensord on top of top output and sometimes just one of these process are occupied with their strange job. I am not sure though that these situations are related.

Update 2015-04-02: @giucam suggested, that it looks like lipstick is busy with rendering. Good guess! top in displaying threads mode shows, that most of the CPU time is consumed by QSGRenderThread thread. I've checked swithcing between the events view / the launcher / a fullscreened app. It does not affect CPU usage.

$ ps -o comm,time -LC lipstick
COMMAND             TIME
lipstick        00:21:57
hwcCommitThr    00:00:00
QThread         00:00:34
QQmlThread      00:00:06
dconf worker    00:00:00
gdbus           00:00:01
QQuickPixmapRea 00:00:00
GL updater      00:05:36
QSGRenderThread 00:26:07    <----little rascal!
QThread         00:00:00
cor::qt::Actor_ 00:00:36
QQuickXmlQueryE 00:00:00
Qt bearer threa 00:00:07
QThread         00:00:01
Qt HTTP thread  00:00:00
QProcessManager 00:00:00

I've noticed, that after several days of phone usage lipstick process starts to constantly use 16% of CPU time. Luckily this happens only when the screen is turned on.

$ ps -FC lipstick
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
nemo       974   913  1 59460 77196   0 Jan21 ?        01:56:51 /usr/bin/lipstick -plugin evdevtouch:/dev/input/event0:rotate=0 -plugin evdevkeyboard:keymap=/usr/share/qt5/keymaps/boston.qmap --systemd

Note consumed CPU time for just a week of usage. If I restart lipstick (attention, following command stops all gui apps):

systemctl --user restart lipstick

It's CPU usage returns to normal ~0% in idle (it might burst sometimes when switching apps or scrolling desktop, but in this case it seems normal).

But after a couple of days lipstick "hangs" again. Seems like a bug to me as it is likely drains battery considerably.

I've tried to investigate the case a bit with strace. A couple of threads of long-running lipstick are heavy busy with futex and reading/writing [eventfd] file descriptor.

Update 2015-02-05: I have a strong feeling that lipstick leaks memory over time as well. Here is memory usage for 2.5 days old lipstick process:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 266164K    writeable/private: 98152K    shared: 46544K

And here is memory usage for freshly started lipstick:

[root@Jolla nemo]# pmap -d `pgrep ^lipstick$` | tail -1
mapped: 206424K    writeable/private: 64396K    shared: 21952K

"writeable/private" is the most relevant number.

If someone has uptime of lipstick more than a week, please post here output of following command (needs root)

pmap -d `pgrep ^lipstick$` | tail -1; ps -FC lipstick

Update 2015-03-07: Looks like my conclusion about memory leak is not correct. Restarting lipstick indeed frees lots of swap space, but the reason is that upon restarting lipstick lots of other services restarts. And most of memory freeing is caused by restarting aliendalvik.

However, in 1.1.2.16 the problem seems to be even more severe. I've seen 24% constant CPU usage and even more.

Update 2015-03-19: It happened again, lipstick uses ~15% CPU user time and ~9% system time constantly when the screen is turned on (~24% total). Stopping all applications and aliendalvik does not help. Data requested by @chris.adams:

• mcetool - screen on
• journalctl -af (turning screen on while following log)

I have not noticed any difference in journalctl messages and mcetool output before and after restarting lipstick, though CPU usage returned to normal after lipstick restart.

Update 2015-03-26: Sometimes sensord process enters similar state: constantly using ~7% CPU when the screen is turned on and goes idle when the screen is turned off. Sometimes I see both lipstick and sensord on top of top output and sometimes just one of these process are occupied with their strange job. I am not sure though that these situations are related.

Update 2015-04-02: @giucam suggested, that it looks like lipstick is busy with rendering. Good guess! top in displaying threads mode shows, that most of the CPU time is consumed by QSGRenderThread thread. I've checked swithcing between the events view / the launcher / a fullscreened app. It does not affect CPU usage.

$ ps -o comm,time -LC lipstick
COMMAND             TIME
lipstick        00:21:57
hwcCommitThr    00:00:00
QThread         00:00:34
QQmlThread      00:00:06
dconf worker    00:00:00
gdbus           00:00:01
QQuickPixmapRea 00:00:00
GL updater      00:05:36
QSGRenderThread 00:26:07    <----little rascal!
QThread         00:00:00
cor::qt::Actor_ 00:00:36
QQuickXmlQueryE 00:00:00
Qt bearer threa 00:00:07
QThread         00:00:01
Qt HTTP thread  00:00:00
QProcessManager 00:00:00

$ ps -o comm,time -LC lipstick
COMMAND             TIME
lipstick        01:10:09
IdleInvalidator 00:00:02
hwcUeventThread 00:00:03
hwcVsyncThread  00:03:12
QEvdevTouchScre 00:01:01
QQmlThread      00:00:07
dconf worker    00:00:00
QDBusConnection 00:05:29
gmain           00:00:00
gdbus           00:00:01
qtaround::mt::A 00:02:16
Qt bearer threa 00:00:47
GL updater      00:01:10
QSGRenderThread 00:55:40
NemoThumbnailLo 00:00:00
QQuickPixmapRea 00:00:05
Qt HTTP thread  00:00:00
Qt HTTP thread  00:00:05
Qt HTTP thread  00:00:00