From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: When should ralloc.c be used? Date: Mon, 24 Oct 2016 09:54:12 +0300 Message-ID: <83h9825jaj.fsf@gnu.org> References: <83k2dihpm9.fsf@gnu.org> <8760p2wzgj.fsf@users.sourceforge.net> <838ttyhhzu.fsf@gnu.org> <871szqwu51.fsf@users.sourceforge.net> <831szqhbc2.fsf@gnu.org> <87d1itt79z.fsf_-_@users.sourceforge.net> <7baa18d4-2b09-caa8-005e-29008a383ad1@cs.ucla.edu> <83mvhwrgd5.fsf@gnu.org> <8539f38f-9a11-44c3-4de7-bb974c96206c@cs.ucla.edu> <8360ojpndr.fsf@gnu.org> <83wpgzo30m.fsf@gnu.org> <5a4bbe6d-08ce-e6c6-39d1-49c9cd6d1ffd@cs.ucla.edu> <83mvhvns9a.fsf@gnu.org> <83d1irnozo.fsf@gnu.org> <83mvhunb0d.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477292111 18757 195.159.176.226 (24 Oct 2016 06:55:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2016 06:55:11 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 24 08:55:07 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1byZA0-00040R-RS for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 08:55:04 +0200 Original-Received: from localhost ([::1]:44919 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byZA3-0005Qf-4n for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 02:55:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33622) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byZ9H-0005IT-5g for emacs-devel@gnu.org; Mon, 24 Oct 2016 02:54:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byZ9D-0002Ny-PN for emacs-devel@gnu.org; Mon, 24 Oct 2016 02:54:19 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43801) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byZ9D-0002Ns-Mz; Mon, 24 Oct 2016 02:54:15 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1342 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1byZ9C-0003eT-SK; Mon, 24 Oct 2016 02:54:15 -0400 In-reply-to: (message from Stefan Monnier on Sun, 23 Oct 2016 16:36:24 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:208657 Archived-At: > From: Stefan Monnier > Cc: Paul Eggert , emacs-devel@gnu.org > Date: Sun, 23 Oct 2016 16:36:24 -0400 > > > Then what are our choices to solve this for Emacs 25.2? If GNU/Linux > > starts using ralloc more and more, we will have crashes and data > > corruption all over the place. It's inconceivable to release 25.2 in > > this state. > > What's wrong with using gmalloc without ralloc and with mmap'd buffers? Nothing, if it works. But someone should set up Emacs to do that, and make sure the result builds, bootstraps, and works reliably, i.e. doesn't have all the problems reported recently in this and related bugs. I don't have access to any platforms that are affected by this (fencepost doesn't yet have such a new glibc). I will do this myself if no one else comes to help, but I really could use help from people who work on platforms that are affected by this issue. Noam and Sam help, but we need more manpower and more expertise. In any case, I asked what were our alternatives, because I'm not sure we have a clear view of those. Making decisions with just a peephole view of the issues is never a good idea. The best solution might not be changing the configury to eliminate ralloc, it could be something entirely different. For example, I see in regex.c a set of special definitions for REGEX_ALLOCATE_STACK and friends conditioned by this: #if defined REL_ALLOC && defined REGEX_MALLOC These definitions call directly a few functions in ralloc.c, as opposed to going via malloc. Does anyone know what is this about? Should we try building with REGEX_MALLOC on platforms that use ralloc.c, and see whether the problems with regex searches triggered by relocation go away? Yet another idea is enlarge the stack space available to SAFE_ALLOCA in regex.c, so that the failure stack is allocated off the C runtime stack, thus side-stepping the relocation issues. And maybe there are other possibilities. We really need to come up with all the possible ideas, try which ones work, and decide as quickly as possible what is the best one. This currently is the most serious blocking issue on the way towards releasing Emacs 25.2 soon, as we wanted to.