Page MenuHomePhabricator

enlightenment-git and efl-git eat huge memory
Open, Incoming QueuePublic

Description

When starting *wayland* session, enlightenment eats about 130M.
After 4 hours running, e eats huge memory:
htop
enlightenment resident memory 4200M
After restarting e, it's ok, about 100M, then after two hours, huge memory eating, about 4045M
system: arch linux, aur packages
last efl-git 1.21.99.59805.g8a1a152d67-1
last enlightenment-git 0.22.99.23417.ga03700103

ProhtMeyhet added a project: Restricted Project.Sep 22 2018, 1:52 AM
ProhtMeyhet added subscribers: devilhorns, ProhtMeyhet.

can you get a valgrind log?

Here is valgrind -massif log. Running enlightenment about 9 hours.
efl-git 1.21.99.59807.ge9e63f3c0d-1
enlightenment-git 0.22.99.23417.ga03700103
https://pastebin.com/C8gq4Khv

My apologize, paste access is public, now...

Maybe useful:
original massive file is massif.out.20204

This comment was removed by maderios.

I apologize for this huge file. Public pastebin doesn't work for me...

It should work
massif file name: 'massif.out.20204'
https://pastebin.com/Y2XsRujj

New valgrind -massif file today, 13 hours running enlightenment.
kernel linux-lts 4.14.71-1
efl-git 1.21.99.59809
enlightenment-git 0.22.99.23417
https://pastebin.com/uVmA2j8C

ManMower added a subscriber: zmike.

I know exactly what this is now, may take a few days to resolve. I don't think massif will even catch it, since it's not on the heap.

When E calls evas_object_image_size_set() on an object with a mmapped dmabuf native surface, the mapping is leaked.

However, simply unmapping at that time sets up a fatal race with the async renderer that will crash.

In the short term the leak can be reduced by setting the env var EVAS_WAYLAND_SHM_DISABLE_DMABUF=1 before launching E, until I get a chance to close this ticket.

Until you solve this problem, e works better with this variable. Thanks.

ManMower removed ManMower as the assignee of this task.Feb 14 2019, 12:14 PM