ubuntu 18.04 LTS, ram filling up completely

[paul-rf]

Hi,
I installed tribler 7.7.0 last friday (downloaded deb file, installation via Ubuntu sw centre) on a ubuntu 18.04 LTS PC as alternative to transmission. Every day I had to reboot the PC as it was completely stuck. Yesterday I started following RAM: after starting tribler I get 4 entries in the list (I have a couple of active torrents), of which 1 starts at ~100 MB RAM, and this continues to grow until the RAM (5 GB in my case) is completely filled up. This morning I stopped tribler, and restarted, but the same behaviour is still there. After installing 7.7.1 and starting today I still see RAM-usage increasing (from 150 M at 14:00 today, to 1.8 G at 18:00).

I am running remmina as remote terminal for the ubuntu 18.04 LTS PC, on a laptop running ubuntu 20.04 LTS, but I cannot imagine that that causes the problem.

Is this expected behaviour? What maximum RAM-usage do you expect from tribler?

I saw a similar problem (issue 2123, 22-4-2016), but I would expect this to be solved in the mean time.

Let me know if you need more information.

[Davem734]

Can confirm.
Problem started with v7.7.0 and still a problem with v7.7.1
Fills up 32Gb of memory after a few hours.
Ubuntu 18.04.5
Python 3.8.5

[Davem734]

Tribler launches four processes.
It is the second (based on PID order) of the four processes that has the memory issue...

[xoriole]

@paul-rf @Davem734 Thank you for reporting and confirming. Currently, Tribler does not set an upper bound on memory usage, but we should cap that and fix the root cause of memory leak. Prioritizing the issue for the release.

[synctext]

wow 32GBytes! That should be easy to locate, thnx!

[egbertbouman]

When I go back before 9d8f961, the GUI process doesn't leak for me anymore. The leak seems to be related to the signal handlers.

[qstokkink]

Inspected gc, this function is leaking:

tribler/src/tribler-gui/tribler_gui/utilities.py

Line 378 in b29e4a6

def trackback_wrapper(*args, **kwargs):

Click me for dirty patch that hooks into the debug window log refresh button to dump the top 5 most-referenced GUI process objects into "memobjs.txt".

diff --git a/src/tribler-gui/tribler_gui/debug_window.py b/src/tribler-gui/tribler_gui/debug_window.py
index ab8c65759..1da1f1b75 100644
--- a/src/tribler-gui/tribler_gui/debug_window.py
+++ b/src/tribler-gui/tribler_gui/debug_window.py
@@ -122,6 +122,9 @@ class DebugWindow(QMainWindow):
         self.rest_request = None
         self.ipv8_health_widget = None
 
+        with open("memobjs.txt", 'w') as f:
+            f.write("")
+
     def hideEvent(self, hide_event):
         self.stop_timer()
         self.hide_ipv8_health_widget()
@@ -771,6 +774,19 @@ class DebugWindow(QMainWindow):
             self.memory_plot_timer.stop()
 
     def load_logs_tab(self):
+        import gc
+        obj_dump = gc.get_objects()
+        out = {}
+        for obj in obj_dump:
+            try:
+                if hasattr(obj, "__code__"):
+                    key = obj.__code__.co_filename + "-" + str(obj.__code__.co_firstlineno)
+                    out[key] = out.get(key, 0) + 1
+            except Exception:
+                pass
+        with open("memobjs.txt", 'a') as f:
+            f.write(repr([repr(k) + "-" + repr(v) for k, v in sorted(out.items(), key=lambda item: item[1])[-5:]]) + "\n")
+        return
         # Max lines from GUI
         max_log_lines = self.window().max_lines_value.text()
 

[ichorid]

According to this report from our forum, the user experiences a leak and a crash on the GUI side. The Core continues to run as normal. I guess it points us to the GUI leaking.

[Davem734]

I noticed that the leak seems to stop (or really slow down) if I am not displaying the "downloads" page...

[kozlovsky]

According to @xoriole experiments, it seems PR #5940 is able to fix the major memory leak, but some minor memory leak still presents. Further debugging is necessary to discover other reasons for memory leaks.

[kozlovsky]

The issue was auto-closed by commit message, but I'm reopening it, as the memory leak was not completely fixed yet

[qstokkink]

Perhaps it would be a good idea to focus some effort on implementing #3603 into the debug screen so we can see what objects are actually leaking.

[sentry-for-tribler]

Sentry issue: SENTRY-FOR-760-28