From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.comp.lib.glibc.alpha,gmane.emacs.devel Subject: Re: Removal of unexec support from glibc malloc Date: Tue, 26 Jan 2016 23:17:35 +0100 Message-ID: <56A7F07F.9000109@redhat.com> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1453846667 1622 80.91.229.3 (26 Jan 2016 22:17:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Jan 2016 22:17:47 +0000 (UTC) Cc: Eli Zaretskii , libc-alpha@sourceware.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: libc-alpha-return-66712-glibc-alpha=m.gmane.org@sourceware.org Tue Jan 26 23:17:46 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 1aOBvl-0002ZZ-Di for glibc-alpha@plane.gmane.org; Tue, 26 Jan 2016 23:17:45 +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:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=OlMAqi1R98g5zmsB J99HDZKJhjmzfj8/v0evM8PvTBes7W1gz8G3kLgQ6aYTkHTzxVZiLKYRTKR2V2Zg +xzoBHNs7CZZwRfejAhLpwxTzhRpeYqhKkV5w/AqoZsMLoCGbW81f5ZzOlgCjdkL 10vlArhr9SyBzxmSu8LW6NP0Flg= 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:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=6RF2teL2Q1HztG6aa3Y/ub X+09Y=; b=hqdSt/L+nDwSCCv1KzbZbtNR3l6sZa4NncRH0bLpNIg7qOgfFjWJk2 rh+ytdV8FjCEHtWzdc50zxEN9Yo4a/bSDApIWNAMZMxMzluyXMSKx8CxEGlRgJS5 N+RsEmk+JDrkqC4L5F/nylzmG+uLlzI6qVxcsSWQELL8YiAX6t514= Original-Received: (qmail 21061 invoked by alias); 26 Jan 2016 22:17:41 -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 21043 invoked by uid 89); 26 Jan 2016 22:17:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=retains, pain, difficulties, HContent-Transfer-Encoding:8bit X-HELO: mx1.redhat.com X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: Xref: news.gmane.org gmane.comp.lib.glibc.alpha:58996 gmane.emacs.devel:198886 Archived-At: On 01/23/2016 11:52 PM, Richard Stallman wrote: [realloc/free of a dumped heap object] > It may be a pain to fix them if they happen inside libraries. I think the dump-and-reload cycle resets global variables defined in libraries as long as they are not referenced by the main program. This means libraries have difficulties to retain references to objects allocated before the dump. If Emacs retains such references and passes them to a library, such boundary-crossing heap operations could still happen. But some libraries will get very confused if they are handed an object while their internal state says they have not created any objects yet. (Which is how we got __malloc_get_state and __malloc_set_state, I assume.) Has it already happened that an innocent-looking library change causes existing Emacs binaries to break? Apart from when glibc tried to fix the incorrect object alignment on 32-bit PowerPC? Florian