From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime Date: Wed, 10 Aug 2011 18:56:09 +0300 Message-ID: <83zkjhxnty.fsf@gnu.org> References: <4E41940C.2010605@cornell.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1312991821 29118 80.91.229.12 (10 Aug 2011 15:57:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 10 Aug 2011 15:57:01 +0000 (UTC) Cc: 9273@debbugs.gnu.org To: Ken Brown Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Aug 10 17:56:56 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QrB9L-00057h-7k for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Aug 2011 17:56:55 +0200 Original-Received: from localhost ([::1]:57215 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrB9K-0007jO-Lh for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Aug 2011 11:56:54 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:41667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrB9G-0007hi-Nn for bug-gnu-emacs@gnu.org; Wed, 10 Aug 2011 11:56:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QrB9F-0007MW-1K for bug-gnu-emacs@gnu.org; Wed, 10 Aug 2011 11:56:50 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33501) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrB9E-0007MQ-O9 for bug-gnu-emacs@gnu.org; Wed, 10 Aug 2011 11:56:48 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QrBAQ-0007R7-BI; Wed, 10 Aug 2011 11:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Aug 2011 15:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9273 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9273-submit@debbugs.gnu.org id=B9273.131299186828566 (code B ref 9273); Wed, 10 Aug 2011 15:58:02 +0000 Original-Received: (at 9273) by debbugs.gnu.org; 10 Aug 2011 15:57:48 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QrBAC-0007Qf-5X for submit@debbugs.gnu.org; Wed, 10 Aug 2011 11:57:48 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QrBAA-0007QX-2O for 9273@debbugs.gnu.org; Wed, 10 Aug 2011 11:57:47 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LPP00100YVJ9G00@a-mtaout22.012.net.il> for 9273@debbugs.gnu.org; Wed, 10 Aug 2011 18:56:08 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.94.185]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LPP00LF3YXIFO61@a-mtaout22.012.net.il>; Wed, 10 Aug 2011 18:56:08 +0300 (IDT) In-reply-to: <4E41940C.2010605@cornell.edu> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 10 Aug 2011 11:58:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:49987 Archived-At: > Date: Tue, 09 Aug 2011 16:09:48 -0400 > From: Ken Brown > > The code in src/gmalloc.c makes assumptions about how a system maintains > its memory that are not necessarily valid. In particular, they will not > be valid on Cygwin starting with version 1.7.10 (which will almost > certainly be released before emacs 24.1). The problem is that malloc > initialization is done by temacs, and the results are dumped into emacs. > This includes the setting __malloc_initialized = 1, so no malloc > initialization is done when emacs is run. But the dumped value of > _heapbase, while appropriate for temacs, may not point to the beginning > of the runtime heap for emacs. This causes all code that uses the BLOCK > and ADDRESS macros to be invalid. If Cygwin developers cannot or won't add to the Cygwin memory allocation enough features and knobs to cater to the special needs of Emacs dumping, then your only hope is to make Cygwin-specific changes to Emacs. You will see that 2 other ports that need to live with Windows memory allocation either have such knobs and features (DJGPP, used to build the DOS port; see the beginning of src/msdos.c) or use their own emulation of sbrk that upholds the contract expected by gmalloc.c and ralloc.c (w32heap.c, for the native Windows build). > But when the dumped emacs is run, it uses Cygwin's sbrk, which > allocates memory on a heap that won't (as of Cygwin 1.7.10) be > contiguous with the static heap. The saved value of _heapbase, > which points into the static heap, is never changed, but it will > mess up later calculations as soon as sbrk is called for the first > time. Are you sure this is all that's at work here? AFAIR, gmalloc does have code to cope with non-contiguous memory regions returned by sbrk. > All of this is described in detail on the Cygwin mailing list in the > thread starting at > > http://cygwin.com/ml/cygwin/2011-08/msg00153.html > > See especially > > http://cygwin.com/ml/cygwin/2011-08/msg00193.html I have read all the discussion there, but I'm sorry to say that I cannot figure out what you are talking about: there's too much Cygwin-isms in that thread that I couldn't penetrate. > Maybe the solution is for emacs to do malloc initialization, including > the assignment of _heapbase, every time it starts, at least on systems > that use gmalloc.c. Most supported systems don't need that. The native Windows build indeed does, see w32heap.c. Perhaps you could reuse some or even most of it for Cygwin. (What is so special about the Cygwin sbrk that is worth sticking to it?) > I made one naive attempt to do this, but it didn't work (and it was > Cygwin specific). Namely, I made unexec (for Cygwin) set > _malloc_initialized = 0 before dumping. The resulting emacs aborted > as soon as it was started. I haven't figured out what went wrong, > but I'm not sure that's the right answer anyway. One more evidence that something else is at work here. I would suggest to walk through the session that reinitializes the heap after unexec and see what goes wrong there.