[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#43389: 28.0.50; Emacs memory leaks using hard disk all time

From: Trevor Bentley
Subject: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Thu, 26 Nov 2020 13:37:54 +0100

You want visibility into what is USING that memory. With glibc-malloc-trace-utils you can try to do that with: LD_PRELOAD=libmtrace.so \ MTRACE_CTL_FILE=/home/user/app.mtr \ MTRACE_CTL_BACKTRACE=1 \ ./app This will use libgcc's unwinder to get a copy of the malloc caller address and then we'll have to decode that based on a /proc/self/maps. Next steps: - Get a glibc-malloc-trace-utils trace of the application ratcheting. - Get a copy of /proc/$PID/maps for the application (shorter version of smaps).

Oh, this is going to be a problem. I guess it is producing one trace file per thread?

I ran it with libmtrace overnight. Memory usage was very high, but it doesn't look like the same problem. I hit 1550MB of RSS, but smaps reported only ~350MB of that was in the heap, which seemed reasonable for the ~150MB that emacs reported it was using. Does libmtrace add a lot of memory overhead?

However, libmtrace has made 4968 files totalling 26GB in that time. Ouch.

It's going to be hard to tell when I hit the bug under libmtrace, questionable whether the report will even fit on my disk, and tricky to share however many tens of gigabytes of trace files it results in.

If it's one trace per thread, though, then we at least know that my emacs process in question is blazing through threads. That could be relevant.

Other thing to note (for Eli): I wrapped garbage-collect like so:

(defun trev/garbage-collect (orig-fun &rest args) (message "%s -- Starting garbage-collect." (current-time-string)) (let ((time (current-time)) (result (apply orig-fun args))) (message "%s -- Finished garbage-collect in %.06f" (current-time-string) (float-time (time-since time))) result)) (add-function :around (symbol-function 'garbage-collect) #'trev/garbage-collect)

This printed a start and stop message each time I evaluated garbage-collect manually. It did not print any messages in 11 hours of running unattended. This is with an active network connection receiving messages fairly frequently, so there was plenty of consing going on. Hard for me to judge if it should run any garbage collection in that time, but I would have expected so.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]