From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.emacs.devel Subject: Re: Dumper issue, revisited; invalid realloc/free Date: Wed, 4 Feb 2015 22:25:50 -0500 Message-ID: <20150205032550.GF23507@brightrain.aerifal.cx> References: <20150204175709.GX23507@brightrain.aerifal.cx> <83pp9pfqb3.fsf@gnu.org> <20150204191305.GY23507@brightrain.aerifal.cx> <83lhkdfpgc.fsf@gnu.org> <54D28260.40403@cornell.edu> <20150205013147.GE23507@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1423106875 11756 80.91.229.3 (5 Feb 2015 03:27:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Feb 2015 03:27:55 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Ken Brown Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 05 04:27:54 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YJD6e-0003Yi-Sp for ged-emacs-devel@m.gmane.org; Thu, 05 Feb 2015 04:27:53 +0100 Original-Received: from localhost ([::1]:39839 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJD6e-00010O-1K for ged-emacs-devel@m.gmane.org; Wed, 04 Feb 2015 22:27:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60901) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJD4v-0006jF-DP for emacs-devel@gnu.org; Wed, 04 Feb 2015 22:26:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJD4s-0006Mk-N1 for emacs-devel@gnu.org; Wed, 04 Feb 2015 22:26:05 -0500 Original-Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:51468 helo=brightrain.aerifal.cx) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJD4o-0006Ld-Nu; Wed, 04 Feb 2015 22:25:58 -0500 Original-Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1YJD4g-0005Bp-00; Thu, 05 Feb 2015 03:25:50 +0000 Content-Disposition: inline In-Reply-To: <20150205013147.GE23507@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 216.12.86.13 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:182423 Archived-At: On Wed, Feb 04, 2015 at 08:31:47PM -0500, Rich Felker wrote: > On Wed, Feb 04, 2015 at 03:34:40PM -0500, Ken Brown wrote: > > On 2/4/2015 2:26 PM, Eli Zaretskii wrote: > > >>Date: Wed, 4 Feb 2015 14:13:05 -0500 > > >>From: Rich Felker > > >>Cc: emacs-devel@gnu.org > > >> > > >>>Yes. Several platforms (Cygwin and MinGW on MS-Windows) already do > > >>>exactly that. > > >> > > >>Where is the code that does this? I don't see it in alloc.c. > > > > > >The Cygwin code is in sheap.c, the MinGW code is in w32heap.c. > > > > > >>Is it only used when system_malloc=no? The case where it's really > > >>needed is for system_malloc=yes... > > > > > >MinGW uses that with system malloc. Not sure about Cygwin. > > > > Cygwin (in the master branch) uses gmalloc.c before dumping and the > > system malloc after dumping. See the code in gmalloc.c involving > > HYBRID_MALLOC. > > Interesting. This is new code I hadn't seen yet (seemingly based on > the conversations last summer) and looks very promising. But I'm > curious -- how do you prevent pointers obtained from the > before-dumping gmalloc from getting passed to the system malloc's > free? If we can solve this I think we have a clean, robust way to get > GNU Emacs building correctly on musl without hacks. After reading the source, I see -- there's a simple range checking macro. Simply removing the #ifdef CYGWIN around all the relevant code seems to make it work with no further hackery, which is very promising, but with current git master I'm hitting lots of lisp failures later in the build process, seemingly due to failure of autoloads to work, although some of the failures don't even seem to be mentioned in autoload.el. Is this kind of failure expected working with bleeding edge (if so I'll seek support somewhere more appropriate), or does it sound like something went wrong in dumping? Rich