Re: Mac OS X: Rebuild Require after Security Update 2002-11-21

[Steven Tamm]

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 <szone_size+160>,
  malloc = 0x90005080 <szone_malloc+160>,
  calloc = 0x90009ac0 <szone_calloc+160>,
  valloc = 0x900159e0 <getattrlist>,
  free = 0x90004380 <szone_free+160>,
  realloc = 0x9000e4a0 <szone_realloc+160>,
  destroy = 0x90064f80 <szone_destroy+160>,
  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 <szone_size>,
  malloc = 0x90004fe0 <szone_malloc>,
  calloc = 0x90009a20 <szone_calloc>,
  valloc = 0x90015940 <szone_valloc>,
  free = 0x900042e0 <szone_free>,
  realloc = 0x9000e400 <szone_realloc>,
  destroy = 0x90064ee0 <szone_destroy>,
  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 <address@hidden>.  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 <address@hidden>.  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
> address@hidden
> http://mail.gnu.org/mailman/listinfo/emacs-devel