[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 16:19:53 +0100

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

I don't see how this could be true, unless some library you use (ImageMagick?) starts a lot of threads. Emacs itself is single-threaded, and the only other threads are those from GTK, which should be very few (like, 4 or 5). This assumes you didn't use Lisp threads, of course.

Oh, it may be subprocesses instead of threads. emacs-slack is doing all sorts of things, involving both ImageMagick and launching curl subprocesses. Is there a way to prevent libmtrace from following children?

I've just hooked make-process and make-thread, and see both being called back-to-back very often for spawning curl subprocesses.

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.

That's expected, because the automatic GC doesn't call garbage-collect. garbage-collect is just a thin wrapper around a C function, called garbage_collect, and the automatic GC calls that function directly from C. And you cannot advise C functions not exposed to Lisp. If you want to have record of the times it took each GC to run, you will have to modify the C sources.

Gotcha.  No surprise, then.


reply via email to

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