From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.comp.lib.glibc.alpha,gmane.emacs.devel Subject: Re: Removal of unexec support from glibc malloc Date: Sat, 23 Jan 2016 17:50:30 +0200 Message-ID: <83wpr047nd.fsf@gnu.org> References: <569CDB81.6040600@redhat.com> <569D3BE0.6050103@cs.ucla.edu> <569D4207.4060209@cs.ucla.edu> <569D6AE6.1060008@redhat.com> <83bn8icjqu.fsf@gnu.org> <83r3h86aqf.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1453564230 4825 80.91.229.3 (23 Jan 2016 15:50:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Jan 2016 15:50:30 +0000 (UTC) Cc: emacs-devel@gnu.org, libc-alpha@sourceware.org To: Stefan Monnier Original-X-From: libc-alpha-return-66532-glibc-alpha=m.gmane.org@sourceware.org Sat Jan 23 16:50:26 2016 Return-path: Envelope-to: glibc-alpha@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aN0SH-0001ZZ-1l for glibc-alpha@plane.gmane.org; Sat, 23 Jan 2016 16:50:25 +0100 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:message-id:from:to:cc:in-reply-to:subject :reply-to:references; q=dns; s=default; b=YVsBFdV5SO5yCZ7by90TWY /eeqXFv/gVYi10PNWCzlpUQV9hBHrilJDswVAG7pLWmoYFRUs32h8nfT0khUPLKI 8UufzP4f108lwEBuc+tttOgawZhu+pHGLCR+Rn7SmYHQK5tpW+TMb9FMB/Hx8uoK ag4mV+ahySVd4dgk1YC4o= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:message-id:from:to:cc:in-reply-to:subject :reply-to:references; s=default; bh=i8ZVIPQkwz389ihggu9pz7oTb5k=; b= lzdB4J5C3CVIwYJdzOjIVvqzbkExllcjhmHKXAkTlL4tyVcXMEgniIYz9AUsbtV5 nSRyHLPetW4gYJIPLvlkNlcwZCQFVXdTkhmkSUI38lFj9H3yh0yS+Q8X32cEEtIF 8c5PgQDSLjN59jWpqahxyHZXkDJSYum1sHGhtQwEykk= Original-Received: (qmail 100902 invoked by alias); 23 Jan 2016 15:50:19 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Original-Received: (qmail 100876 invoked by uid 89); 23 Jan 2016 15:50:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1570, HX-Received-From:134, HX-Received-From:4830, HX-Received-From:2001 X-HELO: eggs.gnu.org In-reply-to: (message from Stefan Monnier on Sat, 23 Jan 2016 10:29:33 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e Xref: news.gmane.org gmane.comp.lib.glibc.alpha:58816 gmane.emacs.devel:198651 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org, libc-alpha@sourceware.org > Date: Sat, 23 Jan 2016 10:29:33 -0500 > > > AFAICS, it happens due to the following: > > . We call regex.c functions, which reuse an allocated buffer, > > extending it (via realloc) as needed; that buffer gets frozen with > > malloc arena used during dumping > > . We delete the terminal frame used by temacs and free its resources > > . Not 100% sure, but I think we also release/reallocate some > > font-related stuff > > It's easy to catch all those cases by setting a breakpoint on realloc > > and free during startup. > > I guess that's what happens in practice, but I'd be surprised if there > aren't more cases that can happen in theory. Right now, anything can happen in theory, because we don't generally write specialized code for temacs, we use the "normal" code, both in Lisp and in C. The only significant difference is the use of 'pure'. > I'm thinking of memory areas allocated for Elisp data which will > *usually* stay live during the lifetime of Emacs, but which could > become free if we do things like re-define some core datastructure > (e.g. I'm thinking of things like (setq global-map (copy-keymap > global-map)). I don't understand the last part of this at all. AFAIU, the problem is not with Lisp data, the problem is with memory allocations on the C level that are not on behalf of Lisp data. We need to find a way of doing that without relying on that data be fee'able after dumping.