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: Sun, 24 Nov 2002 12:37:47 -0800 Sender: emacs-devel-admin@gnu.org Message-ID: <97823BA8-FFEC-11D6-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 1038170428 5880 80.91.224.249 (24 Nov 2002 20:40:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 24 Nov 2002 20:40:28 +0000 (UTC) Cc: 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 18G3YJ-0001Wi-00 for ; Sun, 24 Nov 2002 21:40:27 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18G3db-0003Af-00 for ; Sun, 24 Nov 2002 21:45:55 +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 18G3XO-0001BF-00; Sun, 24 Nov 2002 15:39:30 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18G3W8-0007mS-00 for emacs-devel@gnu.org; Sun, 24 Nov 2002 15:38:12 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18G3W6-0007i7-00 for emacs-devel@gnu.org; Sun, 24 Nov 2002 15:38:12 -0500 Original-Received: from a17-250-248-85.apple.com ([17.250.248.85] helo=smtpout.mac.com) by monty-python.gnu.org with esmtp (Exim 4.10) id 18G3Vm-0007X3-00 for emacs-devel@gnu.org; Sun, 24 Nov 2002 15:37:50 -0500 Original-Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id gAOKbnFR016348 for ; Sun, 24 Nov 2002 12:37:49 -0800 (PST) Original-Received: from mac.com ([12.236.43.16]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id H63LB000.IW2; Sun, 24 Nov 2002 12:37:48 -0800 Original-To: Andrew Choi 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:9654 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9654 Hey Andrew, Well... As you have probably figured out, the update changed libSystem.B and temacs works perfectly after the update. So it must be in unexec. The big problem (as you may have figured out) is that the pointers in emacs_zone are corrupted. After the first call to xrealloc (which calls unexec_realloc) the program fails pretty much instantly. The culprit is the call to emacs_zone->size(). Here is what emacs_zone looks like before (in the version unexec'd before the update): $3 = { reserved1 = 0x0, reserved2 = 0x0, size = 0x900040c0 , malloc = 0x90005080 , calloc = 0x90009ac0 , valloc = 0x900159e0 , free = 0x90004380 , realloc = 0x9000e4a0 , destroy = 0x90064f80 , zone_name = 0x6312c0 "EmacsZone", reserved3 = 0x0, reserved4 = 0x0, introspect = 0xa0001d54, reserved5 = 0x0 } Here is what it looks like after (in the version I redumped after the update): $2 = { reserved1 = 0x0, reserved2 = 0x0, size = 0x90004020 , malloc = 0x90004fe0 , calloc = 0x90009a20 , valloc = 0x90015940 , free = 0x900042e0 , realloc = 0x9000e400 , destroy = 0x90064ee0 , zone_name = 0x6312c0 "EmacsZone", reserved3 = 0x0, reserved4 = 0x0, introspect = 0xa0001d54, reserved5 = 0x0 } szone_size has moved in the system library. So the pointers are corrupted and when unexec_realloc calls emacs_zone->size it goes off into never-never land. The code for malloc_jumpstart in scalable_malloc.c has the following code in it: /* Set function pointers. Even the functions that stay the same must be * set, since there are no guarantees that they will be mapped to the * same addresses. */ data->szones[i].basic_zone.size = (void *) szone_size; This is extremely telling. My first thought on a fix would be to replace the call to emacs_zone->size with a call to szone_size. However that is a static function. All the other malloc zones will have the size set correctly, so using any other malloc zone would work. So here is my proposed change. *** unexmacosx.c.old Sun Nov 24 12:24:03 2002 --- unexmacosx.c Sun Nov 24 12:35:41 2002 *************** *** 888,894 **** /* 2002-04-15 T. Ikegami . The original code to get size failed to reallocate read_buffer (lread.c). */ ! int old_size = emacs_zone->size (emacs_zone, old_ptr); int size = new_size > old_size ? old_size : new_size; if (size) --- 888,894 ---- /* 2002-04-15 T. Ikegami . The original code to get size failed to reallocate read_buffer (lread.c). */ ! int old_size = malloc_default_zone()->size (emacs_zone, old_ptr); int size = new_size > old_size ? old_size : new_size; if (size) I doubt the call to malloc_default_zone will be a performance bottleneck. If it is, during initialization we can call it once and assign emacs_zone->size=malloc_default_zone()->size -Steven On Saturday, November 23, 2002, at 08:04 AM, Andrew Choi wrote: > The following message is a courtesy copy of an article > that has been posted to gnu.emacs.help as well. > > The 2002-11-21 Security Update seems to cause Emacs executables built > before the update to fail. Rebuilding will make them work again. I > realize this is an annoying problem. But I must admit currently I have > no idea how to solve it. > > > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://mail.gnu.org/mailman/listinfo/emacs-devel