From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Failing to GC killed buffers considered harmful Date: Sun, 29 Mar 2020 17:23:02 +0300 Message-ID: <838sjj5jg9.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="125802"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Pip Cet , Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 29 16:23:27 2020 Return-path: Envelope-to: ged-emacs-devel@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 1jIYqU-000Wcc-5P for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Mar 2020 16:23:26 +0200 Original-Received: from localhost ([::1]:38042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIYqT-0005q6-3x for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Mar 2020 10:23:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34040) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIYq0-0005RH-Sh for emacs-devel@gnu.org; Sun, 29 Mar 2020 10:22:57 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51815) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jIYq0-0008KL-EI; Sun, 29 Mar 2020 10:22:56 -0400 Original-Received: from [176.228.60.248] (port=4457 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jIYpz-0007Ix-OK; Sun, 29 Mar 2020 10:22:56 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:245939 Archived-At: This recent change on master: commit afaf2f465188ab1f438ff3e021260e7c529b1b9d Author: Pip Cet AuthorDate: Sat Mar 14 18:26:33 2020 +0000 Commit: Eli Zaretskii CommitDate: Sun Mar 15 16:35:07 2020 +0200 Make sure we mark reachable killed buffers during GC * src/alloc.c (live_buffer_holding): Add ALL_BUFFERS argument for returning killed buffers. (mark_maybe_object, mark_maybe_pointer): Use the additional argument. (Bug#39962) causes us to dump killed buffers in some cases. Presumably, the call to GC right before we start pdumping fails to collect a killed buffer, and it ends up being dumped. When we restore from emacs.pdump, an Emacs built with --enable-checking on a platform that uses mmap for buffer text aborts here: #ifdef USE_MMAP_FOR_BUFFERS if (dumped_with_unexec_p ()) { ... } else { struct buffer *b; /* Only buffers with allocated buffer text should be present at this point in temacs. */ FOR_EACH_BUFFER (b) { eassert (b->text->beg != NULL); <<<<<<<<<<<<<<<<< } } #endif /* USE_MMAP_FOR_BUFFERS */ because a killed buffer has its text freed and set to NULL. We could, of course, remove the assertion, but then we are left with a dead buffer that will never be GC'ed, AFAIU, because objects that come from the portable dump are considered constantly marked. Another idea is to avoid dumping such buffers. But I couldn't find a facility for doing that safely; simply having dump_buffer return causes an assertion violation later: #ifdef ENABLE_CHECKING static Lisp_Object dump_check_overlap_dump_reloc (Lisp_Object lreloc_a, Lisp_Object lreloc_b) { struct dump_reloc reloc_a = dump_decode_dump_reloc (lreloc_a); struct dump_reloc reloc_b = dump_decode_dump_reloc (lreloc_b); eassert (dump_reloc_get_offset (reloc_a) < dump_reloc_get_offset (reloc_b)); return Qnil; } #endif Daniel, did I miss some facility to avoid dumping an object safely? If not, what other solutions could we try, given that whether some pointer into a buffer ends up on the stack at pdump time is something we cannot really control? TIA