[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: |
Carlos O'Donell |
Subject: |
bug#43389: 28.0.50; Emacs memory leaks using hard disk all time |
Date: |
Fri, 27 Nov 2020 00:04:56 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 |
On 11/26/20 3:30 PM, Eli Zaretskii wrote:
>> Cc: trevor@trevorbentley.com, bugs@gnu.support, fweimer@redhat.com,
>> 43389@debbugs.gnu.org, dj@redhat.com, michael_heerdegen@web.de
>> From: Carlos O'Donell <carlos@redhat.com>
>> Date: Thu, 26 Nov 2020 15:21:04 -0500
>>
>> On 11/26/20 8:58 AM, Eli Zaretskii wrote:
>>> Apart of that, I think we really need to see the most significant
>>> customers of these functions when the memory footprint starts growing
>>> fast.
>>
>> It's in the mastiff captured data.
>>
>> Of the 1.7GiB it's all in Fcons:
>>
>> 448.2 MiB: Fmake_list
>> 270.3 MiB: in 262 places all over the place (below massif's threshold)
>> 704.0 MiB: list4 -> exec_byte_code
>> 109.7 MiB: F*_json_read_string_0 -> funcall_subr ...
>> 102.2 MiB: Flist -> exec_byte_code ...
>> 68.5 MiB: Fcopy_alist -> Fframe_parameters ...
>
> Thanks. Those are the low-level primitives, they tell nothing about
> the Lisp code which caused this much memory allocation. We need
> higher levels of callstack, and preferably in Lisp terms. GDB
> backtraces would show them, due to tailoring in src/.gdbinit.
Sure, let me pick one for you:
lisp_align_malloc (alloc.c:1195)
Fcons (alloc.c:2694)
concat (fns.c:730)
Fcopy_sequence (fns.c:598)
timer_check (keyboard.c:4395)
wait_reading_process_output (process.c:5334)
sit_for (dispnew.c:6056)
read_char (keyboard.c:2742)
read_key_sequence (keyboard.c:9551)
command_loop_1 (keyboard.c:1354)
internal_condition_case (eval.c:1365)
command_loop_2 (keyboard.c:1095)
internal_catch (eval.c:1126)
command_loop (keyboard.c:1074)
recursive_edit_1 (keyboard.c:718)
Frecursive_edit (keyboard.c:790)
main (emacs.c:2080)
There is a 171MiB's worth of allocations in that path.
There are a lot of traces ending in wait_reading_process_output that
are consuming 50MiB.
--
Cheers,
Carlos.
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, (continued)
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Jean Louis, 2020/11/25
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Trevor Bentley, 2020/11/25
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Carlos O'Donell, 2020/11/25
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Trevor Bentley, 2020/11/25
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Carlos O'Donell, 2020/11/25
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Eli Zaretskii, 2020/11/26
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Carlos O'Donell, 2020/11/26
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Eli Zaretskii, 2020/11/26
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time,
Carlos O'Donell <=
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Eli Zaretskii, 2020/11/27
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Eli Zaretskii, 2020/11/27
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Eli Zaretskii, 2020/11/27
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Eli Zaretskii, 2020/11/28
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Jean Louis, 2020/11/28
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Trevor Bentley, 2020/11/28
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Trevor Bentley, 2020/11/30
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Eli Zaretskii, 2020/11/30
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Trevor Bentley, 2020/11/30
- bug#43389: 28.0.50; Emacs memory leaks using hard disk all time, Eli Zaretskii, 2020/11/30