From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Unexec dumping results in "Segmentation fault" on Windows Msys2 Date: Fri, 30 Apr 2021 14:24:53 +0300 Message-ID: <834kfoc8vu.fsf@gnu.org> References: <83im52ed8b.fsf@gnu.org> <989be2e0-a090-309b-58cb-8064c6bd5aee@gmail.com> <83y2dycmgr.fsf@gnu.org> <835z0oyrct.fsf@gnu.org> <83eefby1hy.fsf@gnu.org> <64f14133-a647-7406-4908-671258038ae2@gmail.com> <834kg7xqrm.fsf@gnu.org> <79b4e022-5d46-ae76-2192-9e8594c43d8d@gmail.com> <83o8eevwym.fsf@gnu.org> <8ed0330c-482f-3f82-8b37-308328a314b5@gmail.com> <83v98fpmc0.fsf@gnu.org> <37977025-eb33-5456-651d-61fc202a6d9a@gmail.com> <837dkupfat.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40207"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Nikolay Kudryavtsev Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 30 14:23:42 2021 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 1lcSBK-000AMg-CF for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Apr 2021 14:23:42 +0200 Original-Received: from localhost ([::1]:36686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcSBJ-0001zv-Fe for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Apr 2021 08:23:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42606) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcRGe-00074Y-L2 for emacs-devel@gnu.org; Fri, 30 Apr 2021 07:25:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41348) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcRGc-0003jn-HO; Fri, 30 Apr 2021 07:25:08 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1727 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lcRGY-0006eu-Eb; Fri, 30 Apr 2021 07:25:04 -0400 In-Reply-To: (message from Nikolay Kudryavtsev on Thu, 29 Apr 2021 22:17:10 +0300) 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:268659 Archived-At: > From: Nikolay Kudryavtsev > Cc: emacs-devel@gnu.org > Date: Thu, 29 Apr 2021 22:17:10 +0300 > > I now know what's going on there. > > buffer.c/init_buffer has some unexec-specific code that remaps memory > for the special buffers inherited from temacs. We fail at > Fprin1_to_string which uses the " prin1" special buffer. cddf85d256 > removed FOR_EACH_BUFFER macro and replaced it everywhere with the use of > FOR_EACH_LIVE_BUFFER. Because FOR_EACH_LIVE_BUFFER does not iterate over > the " prin1" buffer, it does not get its memory remapped and this breaks > print functionality and elisp compilation, which depends on it. > > FOR_EACH_BUFFER worked before due to buffer structure operating as a > linked list and since it's kind of an ugly way of doing things, make > sense why Stefan removed it. But I'm not if adding those special buffers > to Vbuffer_alist(FOR_EACH_LIVE_BUFFER uses it) would not break anything. Thanks. The " prin1" buffer is not in Vbuffer_alist intentionally. I installed a possible fix for this on master (100% untested), please see if it fixes the problem.