* Mac OS X: Rebuild Require after Security Update 2002-11-21 @ 2002-11-23 16:04 Andrew Choi 2002-11-23 23:49 ` Jason Rumney ` (4 more replies) 0 siblings, 5 replies; 27+ messages in thread From: Andrew Choi @ 2002-11-23 16:04 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-23 16:04 Mac OS X: Rebuild Require after Security Update 2002-11-21 Andrew Choi @ 2002-11-23 23:49 ` Jason Rumney 2002-11-24 19:58 ` Andrew Choi 2002-11-24 6:13 ` Mac OS X: Rebuild Require after Security Update 2002-11-21 Josh DuBois ` (3 subsequent siblings) 4 siblings, 1 reply; 27+ messages in thread From: Jason Rumney @ 2002-11-23 23:49 UTC (permalink / raw) Cc: emacs-devel Andrew Choi <akochoi_nospam_@shaw.ca> writes: > 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. Do you use dynamic linking to system libraries on the Mac at all? This has caused problems between different versions of Windows before. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-23 23:49 ` Jason Rumney @ 2002-11-24 19:58 ` Andrew Choi 2002-11-24 21:03 ` Jason Rumney 0 siblings, 1 reply; 27+ messages in thread From: Andrew Choi @ 2002-11-24 19:58 UTC (permalink / raw) Cc: emacs-devel Jason Rumney <jasonr@gnu.org> writes: > Andrew Choi <akochoi_nospam_@shaw.ca> writes: > > > 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. > > Do you use dynamic linking to system libraries on the Mac at all? > This has caused problems between different versions of Windows before. 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-24 19:58 ` Andrew Choi @ 2002-11-24 21:03 ` Jason Rumney 2002-11-25 23:56 ` Steven Tamm 0 siblings, 1 reply; 27+ messages in thread From: Jason Rumney @ 2002-11-24 21:03 UTC (permalink / raw) Cc: emacs-devel Andrew Choi <akochoi@shaw.ca> 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-24 21:03 ` Jason Rumney @ 2002-11-25 23:56 ` Steven Tamm 2002-11-26 0:18 ` Jason Rumney 2002-11-26 1:19 ` Andrew Choi 0 siblings, 2 replies; 27+ messages in thread From: Steven Tamm @ 2002-11-25 23:56 UTC (permalink / raw) Cc: Andrew Choi, emacs-devel 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 <akochoi@shaw.ca> 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-25 23:56 ` Steven Tamm @ 2002-11-26 0:18 ` Jason Rumney 2002-11-26 1:19 ` Andrew Choi 1 sibling, 0 replies; 27+ messages in thread From: Jason Rumney @ 2002-11-26 0:18 UTC (permalink / raw) Cc: Andrew Choi, emacs-devel Steven Tamm <steventamm@mac.com> writes: > The problem in this case was that a pointer to an operating system > function was being stored in the dumped exec without being updated. Sorry, I wasn't clear. That was what I meant by "initialisation of dynamically loaded functions". ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-25 23:56 ` Steven Tamm 2002-11-26 0:18 ` Jason Rumney @ 2002-11-26 1:19 ` Andrew Choi 2002-11-26 14:53 ` Stefan Monnier 1 sibling, 1 reply; 27+ messages in thread From: Andrew Choi @ 2002-11-26 1:19 UTC (permalink / raw) Cc: emacs-devel Steven Tamm <steventamm@mac.com> writes: > [...] P.S. Andrew, is vfork fixed in Jaguar? If so, we should > probably conditionalize its removal The redirection of vfork to fork is there to solve a problem described by the following comment in src/s/darwin.h (see also the archive of emacs-pretest-bug). /* The following solves the problem that Emacs hangs when evaluating (make-comint "test0" "/nodir/nofile" nil "") when /nodir/nofile does not exist. */ #undef HAVE_WORKING_VFORK #define vfork fork #define DONT_REOPEN_PTY I just tried removing these three lines and Emacs (in fact OS X!) still hangs when evaluating that expression. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-26 1:19 ` Andrew Choi @ 2002-11-26 14:53 ` Stefan Monnier 2002-11-26 16:31 ` Steven Tamm 0 siblings, 1 reply; 27+ messages in thread From: Stefan Monnier @ 2002-11-26 14:53 UTC (permalink / raw) Cc: Steven Tamm, emacs-devel > Steven Tamm <steventamm@mac.com> writes: > > > [...] P.S. Andrew, is vfork fixed in Jaguar? If so, we should > > probably conditionalize its removal > > The redirection of vfork to fork is there to solve a problem described > by the following comment in src/s/darwin.h (see also the archive of > emacs-pretest-bug). > > /* The following solves the problem that Emacs hangs when evaluating > (make-comint "test0" "/nodir/nofile" nil "") when /nodir/nofile > does not exist. */ > #undef HAVE_WORKING_VFORK > #define vfork fork > #define DONT_REOPEN_PTY > > I just tried removing these three lines and Emacs (in fact OS X!) still > hangs when evaluating that expression. Does it really freeze the kernel or just the UI or just Emacs ? If it freezes the kernel, post it to bugtraq as a DoS issue and it should get fixed within a few days. Stefan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-26 14:53 ` Stefan Monnier @ 2002-11-26 16:31 ` Steven Tamm 2002-11-26 17:29 ` Andrew Choi 0 siblings, 1 reply; 27+ messages in thread From: Steven Tamm @ 2002-11-26 16:31 UTC (permalink / raw) Cc: Andrew Choi, emacs-devel It doesn't cause a kernel panic on my box, it just causes the system to become totally unresponsive. The apple version of emacs includes this code around ever call to vfork. #ifndef PUMA_VFORK_ISSUES_CLEARED_UP pid = fork (); #else pid = vfork (); #endif Apparently, puma vfork issues are not cleared up, so it appears the answer is to use fork. I started to do some debugging of this issue, but the fact that after every run the computer hangs makes things quite annoying. I narrowed down the problem (I think). This code works: #include <sys/types.h> #include <unistd.h> int main(int argc, char **argv) { pid_t parent = getpid(); pid_t child; printf("Parent pid %x\n", parent); child = vfork(); if (child < 0) { perror("vfork"); _exit(2); } if (!child) { printf("Child pid %x\n", getpid()); printf("Bad exec return %d\n", execv("/nofile/noplace", argv)); _exit(1); } return 0; } If you remove the _exit(1), it causes a nasty seg fault (it seems to blow away the entire state of the process). If you remove the _exit(1) and switch to fork() it works. So I think the problem may be with vfork not correctly cleaning up after itself if the process goes kablooy. Andrew, did you report a radar issue associated with this? A couple other people tried to switch bash to use vfork, because in later darwin releases the performance of fork seems to have gotten worse. They found similar issues with the system hanging. http://lists.apple.com/archives/darwin-kernel/2002/Oct/02/ forkexecperformance.txt -Steven >> /* The following solves the problem that Emacs hangs when evaluating >> (make-comint "test0" "/nodir/nofile" nil "") when /nodir/nofile >> does not exist. */ >> #undef HAVE_WORKING_VFORK >> #define vfork fork >> #define DONT_REOPEN_PTY >> >> I just tried removing these three lines and Emacs (in fact OS X!) >> still >> hangs when evaluating that expression. > > Does it really freeze the kernel or just the UI or just Emacs ? > If it freezes the kernel, post it to bugtraq as a DoS issue and it > should get fixed within a few days. > > > Stefan > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-26 16:31 ` Steven Tamm @ 2002-11-26 17:29 ` Andrew Choi 2002-11-26 17:45 ` fork v vfork (was Re: Mac OS X: Rebuild Require after Security Update 2002-11-21) Steven Tamm 0 siblings, 1 reply; 27+ messages in thread From: Andrew Choi @ 2002-11-26 17:29 UTC (permalink / raw) Cc: emacs-devel Steven Tamm <steventamm@mac.com> writes: > [...] So I think the problem may be with vfork not correctly cleaning > up after itself if the process goes kablooy. Andrew, did you report a > radar issue associated with this? Hi Steven, No. The problem and fix were submitted by Nozomu Ando on emacs-pretest-bug a while ago. I thought it was acceptable to just use fork so I left it at that. I have not received reports of other problems related to this one. Would you like me to write a bug report to the darwin lists? Seems like they know about the problem with vfork but perhaps we can remind them. Andrew. ^ permalink raw reply [flat|nested] 27+ messages in thread
* fork v vfork (was Re: Mac OS X: Rebuild Require after Security Update 2002-11-21) 2002-11-26 17:29 ` Andrew Choi @ 2002-11-26 17:45 ` Steven Tamm 0 siblings, 0 replies; 27+ messages in thread From: Steven Tamm @ 2002-11-26 17:45 UTC (permalink / raw) Cc: emacs-devel I reported a bug with my test case. It's not that big a deal, I just wanted to make sure that something was being done about it. It's a fairly nasty bug if it hangs the system. It would also make the compile a little cleaner. WRT fork vs. vfork; on darwin the figures I've seen show a difference in performance about 100x, and has been getting worse in each release. What are people's feelings about conditionalizing the three calls to vfork (in process.c, callproc.c, and sysdep.c) so that it could become fork() on platforms that don't have a working VFORK. It would probably use the HAVE_VFORK conditional. -Steven On Tuesday, November 26, 2002, at 09:29 AM, Andrew Choi wrote: > Steven Tamm <steventamm@mac.com> writes: > >> [...] So I think the problem may be with vfork not correctly cleaning >> up after itself if the process goes kablooy. Andrew, did you report a >> radar issue associated with this? > > Hi Steven, > > No. The problem and fix were submitted by Nozomu Ando on > emacs-pretest-bug a while ago. I thought it was acceptable to just use > fork so I left it at that. I have not received reports of other > problems related to this one. > > Would you like me to write a bug report to the darwin lists? Seems > like > they know about the problem with vfork but perhaps we can remind them. > > Andrew. > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-23 16:04 Mac OS X: Rebuild Require after Security Update 2002-11-21 Andrew Choi 2002-11-23 23:49 ` Jason Rumney @ 2002-11-24 6:13 ` Josh DuBois 2002-11-24 14:31 ` Hugo Wolf 2002-11-24 20:37 ` Steven Tamm ` (2 subsequent siblings) 4 siblings, 1 reply; 27+ messages in thread From: Josh DuBois @ 2002-11-24 6:13 UTC (permalink / raw) Not suprisingly (given the thread from 11/11/02), rebuilding won't work for me. I was running 10.2.1 without the security patch unti this evening: tonigth I installed both. My 'bootstrap-emacs' fails with a seg. fault (undefined references to _BC, _PC, and _UP -- all expected from libSystem.B.dylib). In the prior thread lots of folks seemed to be able to build, but all the builds I could find posted are broke on my machine now (prob. from the security patch). Anyone got a working version built *after* installation of the security patch that they can post? (or, better yet, know why the build breaks on some machines?) Oh, yeah - things are the same whether or not I download totally new, fresh source from CVS. Thanks! Josh. In article <m2bs4g9srx.fsf@owlbear.local>, Andrew Choi <akochoi_NOSPAM_@shaw.ca> wrote: > 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-24 6:13 ` Mac OS X: Rebuild Require after Security Update 2002-11-21 Josh DuBois @ 2002-11-24 14:31 ` Hugo Wolf 2002-11-24 18:55 ` Josh DuBois 2002-11-28 17:48 ` Olle Pellijeff 0 siblings, 2 replies; 27+ messages in thread From: Hugo Wolf @ 2002-11-24 14:31 UTC (permalink / raw) In article <241120020014168166%duboisj@codeweavers.com>, Josh DuBois wrote: > Anyone got a working version built *after* installation of the security > patch that they can post? I have one I can post, but I don't have anywhere to post it. If you can point me at server I can upload to, I'll do it immediately. > (or, better yet, know why the build breaks > on some machines?) Several possiblities were mentioned in the earlier discussion. Did you investigate all those? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-24 14:31 ` Hugo Wolf @ 2002-11-24 18:55 ` Josh DuBois 2002-11-24 20:15 ` Hugo Wolf 2002-11-28 17:48 ` Olle Pellijeff 1 sibling, 1 reply; 27+ messages in thread From: Josh DuBois @ 2002-11-24 18:55 UTC (permalink / raw) I wiped all the emacs remnants out of /usr/local and the CVS tip built after that. I always have to make one change when I build, though: I have to add "x-win.el" to the DONTCOMPILE list in lisp/Makefile. I would generate a patch for this, but a.) it's trivial, and b.) I suspect something may be wrong with my build tree, anyway, because I'm still not getting emacs in a .app wrapper. However, I have a terminal version that works so I'll live with that for now. One other note: I had also previously run the disk utility to fix permissions, although on my machine there only seemed to be one file with less permissive attributes than it should have had, and that file was in NetInfo, so I doubt the permissions thing did much for me. Thanks for the help. I hope the notes above can help someone else build. Josh. In article <op5E9.128899$1O2.9316@sccrnsc04>, Hugo Wolf <hwolf@deutsches.lieder.net> wrote: > In article <241120020014168166%duboisj@codeweavers.com>, Josh DuBois wrote: > > Anyone got a working version built *after* installation of the security > > patch that they can post? > > I have one I can post, but I don't have anywhere to post it. If you > can point me at server I can upload to, I'll do it immediately. > > > > (or, better yet, know why the build breaks > > on some machines?) > > Several possiblities were mentioned in the earlier discussion. Did > you investigate all those? > > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-24 18:55 ` Josh DuBois @ 2002-11-24 20:15 ` Hugo Wolf 2002-11-24 21:29 ` Josh DuBois 0 siblings, 1 reply; 27+ messages in thread From: Hugo Wolf @ 2002-11-24 20:15 UTC (permalink / raw) In article <241120021255059837%duboisj@codeweavers.com>, Josh DuBois wrote: > I wiped all the emacs remnants out of /usr/local and the CVS tip built > after that. I had a feeling that was the source of trouble -- either that or not doing 'make distclean' first. > I always have to make one change when I build, though: I have to add > "x-win.el" to the DONTCOMPILE list in lisp/Makefile. I would generate > a patch for this, but > a.) it's trivial, and > b.) I suspect something may be wrong with my build tree, anyway, > because I'm still not getting emacs in a .app wrapper. You shouldn't have to make this change, and you should have an Emacs.app in the emacs/mac directory. Did you run the configure step with "--with-carbon"? Last time this came up someone posted their build steps and they'd omitted this. I pointed it out, but there was never any further response on the subject. > However, I have > a terminal version that works so I'll live with that for now. Is that really any more useful than Apple's build? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-24 20:15 ` Hugo Wolf @ 2002-11-24 21:29 ` Josh DuBois 2002-11-24 22:08 ` Hugo Wolf 0 siblings, 1 reply; 27+ messages in thread From: Josh DuBois @ 2002-11-24 21:29 UTC (permalink / raw) In article <2saE9.129768$QZ.21311@sccrnsc02>, Hugo Wolf <hwolf@deutsches.lieder.net> wrote: > I had a feeling that was the source of trouble -- either that or not > doing 'make distclean' first. > I had done a make distclean already, so it seems to have been the stuff in /usr/local (wouldn't guarantee it, though). > > > I always have to make one change when I build, though: I have to add > > "x-win.el" to the DONTCOMPILE list in lisp/Makefile. I would generate > > a patch for this, but > > a.) it's trivial, and > > b.) I suspect something may be wrong with my build tree, anyway, > > because I'm still not getting emacs in a .app wrapper. > > You shouldn't have to make this change, and you should have an > Emacs.app in the emacs/mac directory. Did you run the configure step > with "--with-carbon"? Last time this came up someone posted their > build steps and they'd omitted this. I pointed it out, but there was > never any further response on the subject. > I specified --with-carbon and --without-x, and I still had to alter the DONTCOMPILE list. I have no X-windows on this machine: do most people build with X installed? > > Is that really any more useful than Apple's build? > No, it's not ;-(. What I really want is a nice LaTeX mode. I've got to go away from my internet connection now, but perhaps I'll try to investigate more when I can. Cheers. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-24 21:29 ` Josh DuBois @ 2002-11-24 22:08 ` Hugo Wolf 2002-11-25 8:11 ` Josh DuBois 0 siblings, 1 reply; 27+ messages in thread From: Hugo Wolf @ 2002-11-24 22:08 UTC (permalink / raw) In article <241120021529133550%duboisj@codeweavers.com>, Josh DuBois wrote: > I specified --with-carbon and --without-x, and I still had to alter the > DONTCOMPILE list. Very strange. Sounds like it's trying to compile something Windows-specific and therefore failing, but I don't understand why these configuration options would lead to that result. > I have no X-windows on this machine: do most people > build with X installed? I don't know about most people, but I've had XFree installed pretty much as long as I've been running osx. I have plenty of occasions to run xemacs remotely on my Mac. Otoh for these purposes it shouldn't matter one way or the other if you configure emacs --without-x (as I do). ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-24 22:08 ` Hugo Wolf @ 2002-11-25 8:11 ` Josh DuBois 0 siblings, 0 replies; 27+ messages in thread From: Josh DuBois @ 2002-11-25 8:11 UTC (permalink / raw) In <Y5cE9.101227$%m4.47751@rwcrnsc52.ops.asp.att.net> Hugo Wolf wrote: Well, in case anyone else is having the same difficulty, my problem was that I had a completely innapropriate build system (I'm running OS 10.2. 2 but had the devtools from 10.1 installed). Now that installed the correct developer tools from apple's web-site cvs compiles out of the box (except for the current, temporary problem with faces.el & cus-face.el), with no modification to exclude x-win.el, and I get an Emacs.app wrapper. Thanks for all the help - hope I didn't add too much confusion to the list. Cheers - Josh. In article <241120021529133550%duboisj@codeweavers.com>, Josh DuBois > wrote: >> I specified --with-carbon and --without-x, and I still had to alter >> the DONTCOMPILE list. > Very strange. Sounds like it's trying to >> compile something > Windows-specific and therefore failing, but I don't understand why > these configuration options would lead to that result. > > > >> I have no X-windows on this machine: do most people >> build with X installed? > > I don't know about most people, but I've had XFree installed pretty > much as long as I've been running osx. I have plenty of occasions to > run xemacs remotely on my Mac. Otoh for these purposes it shouldn't > matter one way or the other if you configure emacs --without-x (as I > do). > > > > > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-24 14:31 ` Hugo Wolf 2002-11-24 18:55 ` Josh DuBois @ 2002-11-28 17:48 ` Olle Pellijeff 1 sibling, 0 replies; 27+ messages in thread From: Olle Pellijeff @ 2002-11-28 17:48 UTC (permalink / raw) In <op5E9.128899$1O2.9316@sccrnsc04> Hugo Wolf wrote: > In article <241120020014168166%duboisj@codeweavers.com>, Josh DuBois > wrote: >> Anyone got a working version built *after* installation of the >> security patch that they can post? > > I have one I can post, but I don't have anywhere to post it. If you > can point me at server I can upload to, I'll do it immediately. I've been saved twice now by http://www.porkrind.org/emacs/ by David Caldwell who's put up dmg packages after the 12.2.2 and now the security patch upgrades. Thank's David! > > >> (or, better yet, know why the build breaks >> on some machines?) > > Several possiblities were mentioned in the earlier discussion. Did > you investigate all those? > > > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-23 16:04 Mac OS X: Rebuild Require after Security Update 2002-11-21 Andrew Choi 2002-11-23 23:49 ` Jason Rumney 2002-11-24 6:13 ` Mac OS X: Rebuild Require after Security Update 2002-11-21 Josh DuBois @ 2002-11-24 20:37 ` Steven Tamm 2002-11-24 21:58 ` Andrew Choi 2002-11-25 4:49 ` Ker Lutyn 2002-11-25 7:40 ` Thorbjørn Ravn Andersen 4 siblings, 1 reply; 27+ messages in thread From: Steven Tamm @ 2002-11-24 20:37 UTC (permalink / raw) Cc: emacs-devel 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 <ikegami@adam.uprr.pr>. 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 <ikegami@adam.uprr.pr>. 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-24 20:37 ` Steven Tamm @ 2002-11-24 21:58 ` Andrew Choi 2002-11-24 23:06 ` Steven Tamm 0 siblings, 1 reply; 27+ messages in thread From: Andrew Choi @ 2002-11-24 21:58 UTC (permalink / raw) Cc: emacs-devel Steven Tamm <steventamm@mac.com> writes: > [...] 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 <ikegami@adam.uprr.pr>. 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 <ikegami@adam.uprr.pr>. 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) Hi Steven, Hey, that's some great debugging!! With your change above, I was able to verify that an executable dumped on 10.2.2 before the security update can be run on one after the update was applied. Please install the change when you can. Somewhat related, while working in unexmacosx.c, I notice the function build_region_list. This function is left over from earlier versions of the file and is unnecessary since dumping is now based on the emacs_zone regions. I'll remove it at some point. Andrew. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-24 21:58 ` Andrew Choi @ 2002-11-24 23:06 ` Steven Tamm 0 siblings, 0 replies; 27+ messages in thread From: Steven Tamm @ 2002-11-24 23:06 UTC (permalink / raw) Cc: emacs-devel Yay. I just checked it in. * unexmacosx.c (unexec_realloc): Use malloc_default_zone to determine the size of pointers alloced in unexed space instead of using possibly invalid emacs_zone pointers. This fixes the binary incompatibility problems caused by updates to libSystem.B. If anybody is making binary distributions publicly available, you should sync the change to unexmacosx.c and rebuild. And I invite anyone to look into adding a pre-flight/post-flight script to the Mac OS X installer to "backup" the apple-provided 21.1 binary if installing into /usr/bin. Some people on versiontracker were complaining. -Steven > Hi Steven, > > Hey, that's some great debugging!! With your change above, I was able > to verify that an executable dumped on 10.2.2 before the security > update > can be run on one after the update was applied. Please install the > change when you can. > > Somewhat related, while working in unexmacosx.c, I notice the function > build_region_list. This function is left over from earlier versions of > the file and is unnecessary since dumping is now based on the > emacs_zone > regions. I'll remove it at some point. > > Andrew. > > > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://mail.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-23 16:04 Mac OS X: Rebuild Require after Security Update 2002-11-21 Andrew Choi ` (2 preceding siblings ...) 2002-11-24 20:37 ` Steven Tamm @ 2002-11-25 4:49 ` Ker Lutyn 2002-11-25 5:02 ` Andrew Choi 2002-11-25 7:40 ` Thorbjørn Ravn Andersen 4 siblings, 1 reply; 27+ messages in thread From: Ker Lutyn @ 2002-11-25 4:49 UTC (permalink / raw) > Rebuilding will make them work again. I, too, have been unable to build emacs from the sources: $ cvs update $ make distclean $ ./configure --with-carbon --without-x $ make bootstrap [...] Recursive `require' for feature `help-fns' make[1]: *** [bootstrap-emacs] Error 255 make: *** [bootstrap] Error 2 Can anyone help me here? Thanks! ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-25 4:49 ` Ker Lutyn @ 2002-11-25 5:02 ` Andrew Choi 0 siblings, 0 replies; 27+ messages in thread From: Andrew Choi @ 2002-11-25 5:02 UTC (permalink / raw) ker527mail@yahoo.com (Ker Lutyn) writes: > > Rebuilding will make them work again. > > I, too, have been unable to build emacs from the sources: > > $ cvs update > $ make distclean > $ ./configure --with-carbon --without-x > $ make bootstrap > [...] > Recursive `require' for feature `help-fns' > make[1]: *** [bootstrap-emacs] Error 255 > make: *** [bootstrap] Error 2 > > Can anyone help me here? Thanks! This is from the News section of my web page. November 24, 2002 The CVS seems broken for bootstrapping again. Please try an earlier version (yesterday's) or try doing this after updating to the latest version before running `make bootstrap': cvs update -r 1.272 lisp/faces.el cvs update -r 1.29 lisp/cus-face.el ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-23 16:04 Mac OS X: Rebuild Require after Security Update 2002-11-21 Andrew Choi ` (3 preceding siblings ...) 2002-11-25 4:49 ` Ker Lutyn @ 2002-11-25 7:40 ` Thorbjørn Ravn Andersen 2002-11-25 8:10 ` Andrew Choi 2002-11-26 11:15 ` Richard Stallman 4 siblings, 2 replies; 27+ messages in thread From: Thorbjørn Ravn Andersen @ 2002-11-25 7:40 UTC (permalink / raw) Cc: emacs-devel Andrew Choi wrote: >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. > Thank you for this information. As I have understood it from this list, the problem is with a library call that exists solely for Emacs to be able to unexec, which is to avoid a lengthy elisp initialization at each startup. Is this still so complicated that it is almost impossible to do "manually" by dumping and restoring the contents of the elisp engine similar to what TeX does? -- Thorbjørn Ravn Andersen Scandiatransplant Skejby Sygehus, indgang 3 +45 89 49 53 01 DK-8200 Århus N http://biobase.dk/~tra ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-25 7:40 ` Thorbjørn Ravn Andersen @ 2002-11-25 8:10 ` Andrew Choi 2002-11-26 11:15 ` Richard Stallman 1 sibling, 0 replies; 27+ messages in thread From: Andrew Choi @ 2002-11-25 8:10 UTC (permalink / raw) Cc: emacs-devel Thorbjørn Ravn Andersen <tra@biobase.dk> writes: > [...] As I have understood it from this list, the problem is with a > library call that exists solely for Emacs to be able to unexec, which > is to avoid a lengthy elisp initialization at each startup. > > Is this still so complicated that it is almost impossible to do > "manually" by dumping and restoring the contents of the elisp engine > similar to what TeX does? > > -- > Thorbjørn Ravn Andersen Steven Tamm has found a solution to this problem. Please see his message posted earlier to the mailing list. Unexec for Mac OS X is implemented in unexmacosx.c. TeX writes out format files in a way that is different from how Emacs does unexec. For one the former are data files while the latter are executable files. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Mac OS X: Rebuild Require after Security Update 2002-11-21 2002-11-25 7:40 ` Thorbjørn Ravn Andersen 2002-11-25 8:10 ` Andrew Choi @ 2002-11-26 11:15 ` Richard Stallman 1 sibling, 0 replies; 27+ messages in thread From: Richard Stallman @ 2002-11-26 11:15 UTC (permalink / raw) Cc: akochoi_nospam_, emacs-devel Is this still so complicated that it is almost impossible to do "manually" by dumping and restoring the contents of the elisp engine similar to what TeX does? Starting Emacs initializes lots of C data structures that are not Lisp data. ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2002-11-28 17:48 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-11-23 16:04 Mac OS X: Rebuild Require after Security Update 2002-11-21 Andrew Choi 2002-11-23 23:49 ` Jason Rumney 2002-11-24 19:58 ` Andrew Choi 2002-11-24 21:03 ` Jason Rumney 2002-11-25 23:56 ` Steven Tamm 2002-11-26 0:18 ` Jason Rumney 2002-11-26 1:19 ` Andrew Choi 2002-11-26 14:53 ` Stefan Monnier 2002-11-26 16:31 ` Steven Tamm 2002-11-26 17:29 ` Andrew Choi 2002-11-26 17:45 ` fork v vfork (was Re: Mac OS X: Rebuild Require after Security Update 2002-11-21) Steven Tamm 2002-11-24 6:13 ` Mac OS X: Rebuild Require after Security Update 2002-11-21 Josh DuBois 2002-11-24 14:31 ` Hugo Wolf 2002-11-24 18:55 ` Josh DuBois 2002-11-24 20:15 ` Hugo Wolf 2002-11-24 21:29 ` Josh DuBois 2002-11-24 22:08 ` Hugo Wolf 2002-11-25 8:11 ` Josh DuBois 2002-11-28 17:48 ` Olle Pellijeff 2002-11-24 20:37 ` Steven Tamm 2002-11-24 21:58 ` Andrew Choi 2002-11-24 23:06 ` Steven Tamm 2002-11-25 4:49 ` Ker Lutyn 2002-11-25 5:02 ` Andrew Choi 2002-11-25 7:40 ` Thorbjørn Ravn Andersen 2002-11-25 8:10 ` Andrew Choi 2002-11-26 11:15 ` Richard Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.