From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time Date: Wed, 20 Jan 2021 09:53:08 -0500 Message-ID: References: <83y2j0qb2v.fsf@gnu.org> <83v9dpn9em.fsf@gnu.org> <87sg8ts766.fsf@mail.trevorbentley.com> <87pn3usr13.fsf@mail.trevorbentley.com> <87eek0rmqa.fsf@mail.trevorbentley.com> <83zh2l33fv.fsf@gnu.org> <87zh2jqnhi.fsf@mail.trevorbentley.com> <837dpn1ccp.fsf@gnu.org> <87zh2i7jqp.fsf@web.de> <83eejue5v8.fsf@gnu.org> <87tusqqa6n.fsf@mail.trevorbentley.com> <833609ena5.fsf@gnu.org> <87r1ntqz4c.fsf@mail.trevorbentley.com> <83pn3dcx89.fsf@gnu.org> <87mtyhqxy1.fsf@mail.trevorbentley.com> <83o8ixcv9v.fsf@gnu.org> <87k0tlqvzv.fsf@mail.trevorbentley.com> <83mtyhcbno.fsf@gnu.org> <87ft48qdw7.fsf@mail.trevorbentley.com> <87k0s7q0j4.fsf@mail.trevorbentley.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5836"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: fweimer@redhat.com, 43389@debbugs.gnu.org, dj@redhat.com, bugs@gnu.support, carlos@redhat.com, michael_heerdegen@web.de To: Trevor Bentley Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 20 15:54:14 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l2EsA-0001MK-2G for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 20 Jan 2021 15:54:14 +0100 Original-Received: from localhost ([::1]:49566 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l2Es9-0008Tf-4U for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 20 Jan 2021 09:54:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37548) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l2Ery-0008Ry-E6 for bug-gnu-emacs@gnu.org; Wed, 20 Jan 2021 09:54:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41793) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l2Ery-0007gY-5J for bug-gnu-emacs@gnu.org; Wed, 20 Jan 2021 09:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l2Ery-0006do-3N for bug-gnu-emacs@gnu.org; Wed, 20 Jan 2021 09:54:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 20 Jan 2021 14:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43389 X-GNU-PR-Package: emacs Original-Received: via spool by 43389-submit@debbugs.gnu.org id=B43389.161115439925477 (code B ref 43389); Wed, 20 Jan 2021 14:54:02 +0000 Original-Received: (at 43389) by debbugs.gnu.org; 20 Jan 2021 14:53:19 +0000 Original-Received: from localhost ([127.0.0.1]:53339 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l2ErH-0006cp-A1 for submit@debbugs.gnu.org; Wed, 20 Jan 2021 09:53:19 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40193) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l2ErF-0006cd-JM for 43389@debbugs.gnu.org; Wed, 20 Jan 2021 09:53:18 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 251DD101137; Wed, 20 Jan 2021 09:53:12 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id AA32A1000DA; Wed, 20 Jan 2021 09:53:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1611154389; bh=XMa10L486h5VjAoBNwAMyaTmaQWxH4AhcbVvQDTk/7w=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=G1kie8/SeRuxo4CKRB7+Yo67/4Uz66UtzbTAtbCJBugJ6dUEpzAfXpiM7TakpDabF drNL/xFVkaCIDfpT083gS14tX2/S6/HuJLzqijVPvy4/eKQiDqLKrnjblxsB6seIa1 0iKZ9DVONwe862N+vpwSmffkxl+20jfrwatmD8z0OVZhnREPxMeLsyzarXDi9DMX4q 5B7OXMW1PAgpOICiqJpDVdS5mwMxqB6sbnyOkurw/nHbo/CZl/R7rFiBfS95KCWLDI bQtZzV4mt3ZN70bPhm0kQEHFegMtapJ7O4ndokyg+5koLRdZ0DM3GntVLAqUzy1wOR 8pTOxL0/M5z0Q== Original-Received: from alfajor (unknown [45.72.224.181]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5029C1204F0; Wed, 20 Jan 2021 09:53:09 -0500 (EST) In-Reply-To: <87k0s7q0j4.fsf@mail.trevorbentley.com> (Trevor Bentley's message of "Wed, 20 Jan 2021 13:02:23 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:198259 Archived-At: > If you have a look at this long backtrace, you can see that we are inside > a garbage_collect call (frame #38). An X11 focus event comes in, triggering > a bunch of GTK/GDK/X calls. Mysteriously, this leads to a maybe_quit() call > which in turn calls longjmp(). longjmp jumps right out of the garbage > collect, leaving it unfinished. Indeed, thanks! > I don't know emacs internals, so you'll have to figure out if this is > X dependent (probably) and/or GTK dependent. It should be possible to come > up with an easier way to reproduce it now. The backtrace is clear enough, no need to reproduce it. The GC properly speaking is actually finished at that point, BTW (luckily: I think you'd have seen worse outcomes if that weren't the case ;-). I installed the simple patch below into `master. It should fix the immediate problem of failing to set consing_until_gc back to a sane value and it should also fix the other immediate problem of getting to `siglongjmp` from `unblock_input` via `window_parameter`. Eli, do you think it should go to `emacs-27`? > Backtrace: > ----------- > (gdb) bt > #0 0x00007ffff5571230 in siglongjmp () at /usr/lib/libc.so.6 > #1 0x00005555557bd38d in unwind_to_catch (catch=0x555555dfc320, type=NONLOCAL_EXIT_THROW, value=0x30) at eval.c:1181 > #2 0x00005555557bd427 in Fthrow (tag=0xe75830, value=0x30) at eval.c:1198 > #3 0x00005555557bdea7 in process_quit_flag () at eval.c:1526 > #4 0x00005555557bdeef in maybe_quit () at eval.c:1547 > #5 0x00005555557cbbb1 in Fassq (key=0xd0b0, alist=0x55555901c573) at fns.c:1609 > #6 0x0000555555632b63 in window_parameter (w=0x555555f2d088, parameter=0xd0b0) at window.c:2262 > #7 0x000055555563a075 in window_wants_tab_line (w=0x555555f2d088) at window.c:5410 > #8 0x00005555555c22b1 in get_phys_cursor_geometry (w=0x555555f2d088, row=0x55555d9f3ef0, glyph=0x55555fd20e00, xp=0x7fffffff9c48, yp=0x7fffffff9c4c, heightp=0x7fffffff9c50) at xdisp.c:2650 > #9 0x00005555556c1b12 in x_draw_hollow_cursor (w=0x555555f2d088, row=0x55555d9f3ef0) at xterm.c:9495 > #10 0x00005555556c24f9 in x_draw_window_cursor (w=0x555555f2d088, glyph_row=0x55555d9f3ef0, x=32, y=678, cursor_type=HOLLOW_BOX_CURSOR, cursor_width=1, on_p=true, active_p=false) at xterm.c:9682 > #11 0x000055555561a922 in display_and_set_cursor (w=0x555555f2d088, on=true, hpos=2, vpos=18, x=32, y=678) at xdisp.c:31738 > #12 0x000055555561aa5b in update_window_cursor (w=0x555555f2d088, on=true) at xdisp.c:31773 > #13 0x000055555561aabf in update_cursor_in_window_tree (w=0x555555f2d088, on_p=true) at xdisp.c:31791 > #14 0x000055555561aaab in update_cursor_in_window_tree (w=0x55555907a490, on_p=true) at xdisp.c:31789 > #15 0x000055555561aaab in update_cursor_in_window_tree (w=0x55555a514b68, on_p=true) at xdisp.c:31789 > #16 0x000055555561ab37 in gui_update_cursor (f=0x555556625468, on_p=true) at xdisp.c:31805 > #17 0x00005555556b9829 in x_frame_unhighlight (f=0x555556625468) at xterm.c:4490 > #18 0x00005555556ba22d in x_frame_rehighlight (dpyinfo=0x55555626d6c0) at xterm.c:4852 > #19 0x00005555556b98fc in x_new_focus_frame (dpyinfo=0x55555626d6c0, frame=0x0) at xterm.c:4520 > #20 0x00005555556b9a3d in x_focus_changed (type=10, state=2, dpyinfo=0x55555626d6c0, frame=0x555556625468, bufp=0x7fffffffa0d0) at xterm.c:4554 > #21 0x00005555556ba0a6 in x_detect_focus_change (dpyinfo=0x55555626d6c0, frame=0x555556625468, event=0x7fffffffa840, bufp=0x7fffffffa0d0) at xterm.c:4787 > #22 0x00005555556c0235 in handle_one_xevent (dpyinfo=0x55555626d6c0, event=0x7fffffffa840, finish=0x555555c901d4 , hold_quit=0x7fffffffab50) at xterm.c:8810 > #23 0x00005555556bde28 in event_handler_gdk (gxev=0x7fffffffa840, ev=0x55555cccf0c0, data=0x0) at xterm.c:7768 > #24 0x00007ffff75f780f in () at /usr/lib/libgdk-3.so.0 > #25 0x00007ffff75fb3cb in () at /usr/lib/libgdk-3.so.0 > #26 0x00007ffff759f15b in gdk_display_get_event () at /usr/lib/libgdk-3.so.0 > #27 0x00007ffff75fb104 in () at /usr/lib/libgdk-3.so.0 > #28 0x00007ffff6fcb8f4 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 > #29 0x00007ffff701f821 in () at /usr/lib/libglib-2.0.so.0 > #30 0x00007ffff6fca121 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 > #31 0x00007ffff784e2c7 in gtk_main_iteration () at /usr/lib/libgtk-3.so.0 > #32 0x00005555556c1821 in XTread_socket (terminal=0x5555560b7460, hold_quit=0x7fffffffab50) at xterm.c:9395 > #33 0x000055555570f3a2 in gobble_input () at keyboard.c:6890 > #34 0x000055555570f894 in handle_async_input () at keyboard.c:7121 > #35 0x000055555570f8dd in process_pending_signals () at keyboard.c:7139 > #36 0x000055555570f9cf in unblock_input_to (level=0) at keyboard.c:7162 > #37 0x000055555570fa4c in unblock_input () at keyboard.c:7187 > #38 0x000055555578f49a in garbage_collect () at alloc.c:6121 > #39 0x000055555578efe7 in maybe_garbage_collect () at alloc.c:5964 > #40 0x00005555557bb292 in maybe_gc () at lisp.h:5041 > #41 0x00005555557c12d6 in Ffuncall (nargs=2, args=0x7fffffffad68) at eval.c:2793 > #42 0x000055555580f7d6 in exec_byte_code > ... -------------- Of course, there might be other places where we could get to `maybe_quit` from `XTread_socket`, given the enormous amount of code it can execute. :-( Stefan diff --git a/src/alloc.c b/src/alloc.c index c0a55e61b9..b86ed4ed26 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -6101,11 +6101,13 @@ garbage_collect (void) gc_in_progress = 0; - unblock_input (); - consing_until_gc = gc_threshold = consing_threshold (gc_cons_threshold, Vgc_cons_percentage, 0); + /* Unblock *after* re-setting `consing_until_gc` in case `unblock_input` + signals an error (see bug#43389). */ + unblock_input (); + if (garbage_collection_messages && NILP (Vmemory_full)) { if (message_p || minibuf_level > 0) diff --git a/src/window.c b/src/window.c index e025e0b082..eb16e2a433 100644 --- a/src/window.c +++ b/src/window.c @@ -2260,7 +2260,7 @@ DEFUN ("window-parameters", Fwindow_parameters, Swindow_parameters, Lisp_Object window_parameter (struct window *w, Lisp_Object parameter) { - Lisp_Object result = Fassq (parameter, w->window_parameters); + Lisp_Object result = assq_no_quit (parameter, w->window_parameters); return CDR_SAFE (result); }