Project

General

Profile

Bug #9281

Marco - The MATE Window Manager

Added by Espen Martinsen almost 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2018-03-14
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

marco 1.18.1

Something happened between my upgrade done 20180220 and my next upgrade 2018030.
marco, the wm, works fine until the upgrade on 2018030, where it graduately starts to eat my cpu's.
after some hours, it suddenly uses 7-8% of the cpu, and things starts to be unresponsive. I can fix this my running "marco --replace", and it runs for a while again before everything starts to slow down again.

OIhipster-20180220
$ ls -l /usr/bin/marco
-r-xr-xr-x 1 root bin 723000 Feb 20 19:43 /usr/bin/marco
$ md5sum /usr/bin/marco
9843085b7cfb6f40c206cc91a9a2780d /usr/bin/marco

NEW, eats CPU:
pfexec beadm mount OIhipster-20180309
Mounted successfully on: '/tmp/tmp.UlaqCm'
$ cd /tmp/tmp.UlaqCm
$ ls -l usr/bin/marco
-r-xr-xr-x 1 root bin 839600 Mar 9 14:49 usr/bin/marco
$ md5sum usr/bin/marco
b1e6c9540aa8daf36b80501c10bdf25e usr/bin/marco

Both binaries reports to be version 1.18.1


Files

marco.truss.zip (468 KB) marco.truss.zip Espen Martinsen, 2018-03-19 11:40 AM
marco.jpg (30.6 KB) marco.jpg prstat showing marco eating ~10% cpu Espen Martinsen, 2018-03-24 02:36 PM

History

#1

Updated by Espen Martinsen almost 2 years ago

$ file marco marco.OIh*
marco: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, not stripped, no debugging information available
marco.OIhipster-20180220: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped
marco.OIhipster-20180311: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, not stripped, no debugging information available

When the marco starts eating cpu-time, I restarted with the 32bit-version: $marco.OIhipster-20180220 --replace &
and everything runs fine (for 3 days now)

#2

Updated by Aurélien Larcher almost 2 years ago

At the end of the day we'll have to move away from 32-bit so it would be good to root cause the issue and fix it.
If you have any data to provide this would help. In particular what is marco doing while eating cycles?

#3

Updated by Espen Martinsen almost 2 years ago

II'll see what I can find.
If noone else has reported the same, it could be a "local" problem. I'll see if it is the same with a fresh $HOME, the one I'm using has been in use since the early openindiana 151-a-something.

#4

Updated by Espen Martinsen almost 2 years ago

Hi,

Started ewith 64-bit marco again, everything works fine, most used programs:
xterm + mate-terminal + firefox + thunderbird + rdesktop + rhythmbox + virtualbox.

After ~ 2 hours, CPU starts raise on "marco in my prstat-window.

Start a "pfexec /opt/DTT/dtruss -f -p <pid_of_marco> > marco.truss 2>&1" (attached, zipped)

several other measurements: ie 5-10 seconds, (moving some windows while waiting)
prstat:
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
19662 esm 99M 63M sleep 45 0 0:40:35 3.8% marco/4
12551 esm 209M 86M sleep 59 0 0:22:52 0.5% rhythmbox/25
3669 esm 5427M 5361M sleep 59 0 4:35:29 0.2% VBoxHeadless/121
2168 esm 142M 5760K sleep 59 0 0:08:02 0.2% pulseaudio/3
3090 esm 674M 381M sleep 49 0 2:07:19 0.2% thunderbird/57
1250 esm 407M 346M sleep 59 0 1:06:24 0.2% Xorg/3
3042 esm 175M 104M sleep 59 0 0:04:22 0.1% mate-terminal/4

Comment: normally, marco uses between 0.1 and 0.5

syscall by execname:
...
thunderbird 10652
Xorg 21384
pulseaudio 29635
rhythmbox 33255
marco 748165

syscall by syscall:
...
mmap 79252
munmap 79278
close 79324
open 79356
stat 158574

read bytes by processname:
..
mate-volume-cont 15448
Xorg 23312
pulseaudio 56654
rhythmbox 107483
prstat 129792
marco 612234

  1. Files opened by process name,
    dtrace -n 'syscall::open*:entry { printf("%s %s",execname,copyinstr(arg0)); }'
    ....
    7 11000 open:entry marco /usr/lib/X11/locale/common/xlcUTF8Load.so.2
    7 11000 open:entry marco /usr/lib/X11/locale/common/xlcUTF8Load.so.2
    7 11000 open:entry marco /usr/lib/X11/locale/common/xlcUTF8Load.so.2
    7 11000 open:entry marco /usr/lib/X11/locale/common/xlcUTF8Load.so.2
    7 11000 open:entry marco /usr/lib/X11/locale/common/xlcUTF8Load.so.2
    7 11000 open:entry marco /usr/lib/X11/locale/common/xlcUTF8Load.so.2
    7 11000 open:entry marco /usr/lib/X11/locale/common/xlcUTF8Load.so.2
    7 11000 open:entry marco /usr/lib/X11/locale/common/xlcUTF8Load.so.2
    7 11000 open:entry marco /usr/lib/X11/locale/common/xlcUTF8Load.so.2
    ...
  2. Minor faults by process name,
    dtrace -n 'vminfo:::as_fault { @mem[execname] = sum(arg0); }'
    dconf-service 6
    rhythmbox 12
    gtk-window-decor 42
    wnck-applet 42
    dtrace 106
    VBoxHeadless 1122
    thunderbird 32103
    marco 241697

Please tell me if there is any other things I shall try, happy to help, but I'm no developer....

#5

Updated by Espen Martinsen almost 2 years ago

Hi,
I'm now starting a test with a scratched $HOME. Don't put too much effort into this before I've seen the problem in this test as well.

-espen

#6

Updated by Espen Martinsen almost 2 years ago

After running for some hours from an absolutely clean $HOME, and left laptop powered on over night, marco has taken more than 9% of the cpu, and it is almost not possible to grab focus on the screen.

After a while, I managed to start a dtruss -p <pid> of marco, and this is what it says:

10460/1: pollsys(0xFFFFFD7FFFDFEBD8, 0x1, 0x0) = 1 0
10460/1: recvmsg(0x6, 0xFFFFFD7FFFDFEB00, 0x8000) = 32 0
10460/1: pollsys(0xFFFFFD7FFFDFEBD8, 0x1, 0x0) = 1 0
10460/1: recvmsg(0x6, 0xFFFFFD7FFFDFEB00, 0x8000) = 64 0
10460/1: pollsys(0xFFFFFD7FFFDFEBD8, 0x1, 0x0) = 1 0
10460/1: recvmsg(0x6, 0xFFFFFD7FFFDFEB00, 0x8000) = 64 0
10460/1: pollsys(0xFFFFFD7FFFDFEBD8, 0x1, 0x0) = 1 0
10460/1: recvmsg(0x6, 0xFFFFFD7FFFDFEB00, 0x8000) = 32 0
10460/1: pollsys(0xFFFFFD7FFFDFEBD8, 0x1, 0x0) = 1 0
10460/1: recvmsg(0x6, 0xFFFFFD7FFFDFEB00, 0x8000) = 32 0
10460/1: pollsys(0xFFFFFD7FFFDFEBD8, 0x1, 0x0) = 1 0
10460/1: recvmsg(0x6, 0xFFFFFD7FFFDFEB00, 0x8000) = 32 0
10460/1: pollsys(0xFFFFFD7FFFDFEBD8, 0x1, 0x0) = 1 0
10460/1: recvmsg(0x6, 0xFFFFFD7FFFDFEB00, 0x8000) = 32 0
10460/1: pollsys(0xFFFFFD7FFFDFEBD8, 0x1, 0x0) = 1 0
10460/1: recvmsg(0x6, 0xFFFFFD7FFFDFEB00, 0x8000) = 32 0

.. never ending....

$ uname -a
SunOS esmpc 5.11 illumos-84c66da4cd i86pc i386 i86pc Solaris
$ psrinfo -vp
The physical processor has 4 cores and 8 virtual processors (0-7)
The core has 2 virtual processors (0-1)
The core has 2 virtual processors (2-3)
The core has 2 virtual processors (4-5)
The core has 2 virtual processors (6-7)
x86 (GenuineIntel 306A9 family 6 model 58 step 9 clock 2400 MHz)
Intel(r) Core(tm) i7-3630QM CPU @ 2.40GHz

$ prtconf | grep "Memory size" | awk '{print $3}'
16149

If someone wants me to do any other debugging, they have to explain what to do. In the meantime, my workaround is to run 32bit-marco from february.

-espenM

!!

#7

Updated by Espen Martinsen almost 2 years ago

Hi,
I did an update on the 29th of march, but still see that marco is the same.

md5sum marco*
b1e6c9540aa8daf36b80501c10bdf25e marco
b1e6c9540aa8daf36b80501c10bdf25e marco.OIhipster-20180311

$ file marco
marco: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, not stripped, no debugging information available

But nevertheless, it looks like it has silenced.
It have now been running for 5 days without problems.

close case!

-espen M

#8

Updated by Ken Mays almost 2 years ago

We can close this ticket. Tested 4/21/18. No issues.

#9

Updated by Alexander Pyhalov almost 2 years ago

  • Status changed from New to Closed

Can be related to 64-bit libX11 issue, but I'm just guessing. Anyway as issue is not reproducible, I close it for now.

Also available in: Atom PDF