From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Steven Tamm Newsgroups: gmane.emacs.devel Subject: Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 Date: Mon, 25 Nov 2002 15:56:13 -0800 Sender: emacs-devel-admin@gnu.org Message-ID: <7A93436F-00D1-11D7-AD9F-00039390AB82@mac.com> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v548) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1038269035 18193 80.91.224.249 (26 Nov 2002 00:03:55 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 26 Nov 2002 00:03:55 +0000 (UTC) Cc: Andrew Choi , emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18GTCh-0004j7-00 for ; Tue, 26 Nov 2002 01:03:51 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18GTIX-0001KA-00 for ; Tue, 26 Nov 2002 01:09:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18GT6L-00066w-00; Mon, 25 Nov 2002 18:57:17 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18GT5T-0005XG-00 for emacs-devel@gnu.org; Mon, 25 Nov 2002 18:56:23 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18GT5Q-0005U6-00 for emacs-devel@gnu.org; Mon, 25 Nov 2002 18:56:22 -0500 Original-Received: from smtpout.mac.com ([17.250.248.86]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18GT5M-0005TS-00; Mon, 25 Nov 2002 18:56:16 -0500 Original-Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id gAPNuaoD028652; Mon, 25 Nov 2002 15:56:37 -0800 (PST) Original-Received: from mac.com ([12.236.43.16]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id H65P5Q00.1US; Mon, 25 Nov 2002 15:56:14 -0800 Original-To: Jason Rumney In-Reply-To: X-Mailer: Apple Mail (2.548) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9673 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9673 So far, it appears that DLL initialization is not the problem. The mach-o format seems to guarantee that library initialization occurs upon dynamic linking. Since the Carbon framework/library isn't called during unexec (restricting initialization to UNIXish type things), this makes sense. The problem in this case was that a pointer to an operating system function was being stored in the dumped exec without being updated. The heartening thing is that the apple/next version of unexec implied that these were the only pointers that had to be reinitialized post-dumping. However it does appear that unlike the apple/next version, the Carbon version seems to initialize some of the core foundation code during unexec (if this was untrue, using malloc_freezedry and malloc_jumpstart would work). This is troublesome because none of the Carbon calls are ever made before dumping; just by linking with the Framework does this initialization happen. I put some effort into finding out why this happens and it seems to back up the first point; the Carbon framework initializes some structures on exec regardless of whether it is called during the lifetime of the program. If anyone familiar with next/darwin/mach-o had any ideas on how to prevent the Carbon framework/library from initializing itself, it would be greatly appreciated. That way the unexec code could go back to using malloc_freezedry and malloc_jumpstart (and make a lot of these issues disappear). -Steven P.S. Andrew, is vfork fixed in Jaguar? If so, we should probably conditionalize its removal On Sunday, November 24, 2002, at 01:03 PM, Jason Rumney wrote: > Andrew Choi writes: > >> Thanks. Yes, that's probably the cause. Unfortunately dynamically >> linked libraries are the only choice for using most of the "system >> frameworks" on Mac OS X. I'm currently trying to determine whether >> some >> variables in the libraries are somehow unexec'ed along with the Emacs >> heap. Of course this will cause a problem if the new libraries change >> the variables' locations. There aren't many tools available to look >> into this. But I'll figure out a way sooner or later. > > In the case where this caused problems on Windows, it was because the > initialization of the dynamically loaded functions was happening only > when Emacs was dumped. To work across OS updates, you need to make > sure that the initialization is run every time Emacs runs. > > > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://mail.gnu.org/mailman/listinfo/emacs-devel