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

[Steven Tamm]

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 <address@hidden> 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
> address@hidden
> http://mail.gnu.org/mailman/listinfo/emacs-devel