Mac OS X 10.2.2 - Need to Recompile

Mac OS X 10.2.2 - Need to Recompile

[Steven Tamm]

I just updated to Mac OS X 10.2.2 and the emacs I was using (compiled 
in 10.2.1) stopped working (similar to the update between 10.1 and 
10.2).  Recompiling fixed everything, so it's not a huge problem.  
Seems that there is a new version of libSystem.B included in 10.2.2, 
which is incompatible.

The error I got was here:

#0  0x90004248 in szone_size ()
#1  0x000b0b0c in xrealloc (block=0x0, size=321) at alloc.c:542
#2  0x00006240 in adjust_frame_message_buffer (f=0x63aec0) at 
dispnew.c:2435
#3  0x00005c20 in adjust_frame_glyphs (f=0x63aec0) at dispnew.c:2133
#4  0x00005bcc in adjust_frame_glyphs_initially () at dispnew.c:2115
#5  0x0000c6e4 in init_display () at dispnew.c:6537

It occurs on the first call to realloc with a non-empty block.  The 
darwin source is hard to follow at this point as malloc blocks are 
controlled in objc code.

Does anyone else see this problem?
-Steven

Re: Mac OS X 10.2.2 - Need to Recompile

[Brad Miller]

I had the same problem this morning after updating to 10.2.2 last night.

My first attempt, was to do something simple:
make clean
make
That didn't solve it...  Emacs still died right after launch.
make distclean
make
Same result.  For some reason this never works like I would expect it 
to for the mac build.  Is there a better/different clean target that I 
should use?

So, I removed the emacs directory and checked out a clean copy from CVS.
./configure --without-x
make bootstrap

Now I get a bunch of warnings like this one, chosen at random:
keyboard.c:62: warning: could not use precompiled header 
'/usr/include/unistd-gcc3.p', because:
keyboard.c:62: warning: macro 'select' defined by ./s/darwin.h 
conflicts with precomp

Finally the compile dies a horrible death at:
Compiling /Users/bmiller/src/emacs/lisp/progmodes/cc-mode.el
 >>Error occurred processing 
/Users/bmiller/src/emacs/lisp/progmodes/cc-mode.el: Symbol's function 
definition is void ((char-table-p))
make[1]: *** [compile] Error 1
make: *** [bootstrap] Error 2

Uggh!  Now I'm really stuck.  Any thoughts on what I can do?

Thanks,

Brad

On Tuesday, November 12, 2002, at 03:22 AM, emacs-devel-request@gnu.org 
wrote:

>
> --__--__--
>
> Message: 7
> Date: Mon, 11 Nov 2002 19:34:24 -0800
> Subject: Mac OS X 10.2.2 - Need to Recompile
> From: Steven Tamm <steventamm@mac.com>
> To: emacs-devel@gnu.org
>
> I just updated to Mac OS X 10.2.2 and the emacs I was using (compiled
> in 10.2.1) stopped working (similar to the update between 10.1 and
> 10.2).  Recompiling fixed everything, so it's not a huge problem.
> Seems that there is a new version of libSystem.B included in 10.2.2,
> which is incompatible.
>
> The error I got was here:
>
> #0  0x90004248 in szone_size ()
> #1  0x000b0b0c in xrealloc (block=0x0, size=321) at alloc.c:542
> #2  0x00006240 in adjust_frame_message_buffer (f=0x63aec0) at
> dispnew.c:2435
> #3  0x00005c20 in adjust_frame_glyphs (f=0x63aec0) at dispnew.c:2133
> #4  0x00005bcc in adjust_frame_glyphs_initially () at dispnew.c:2115
> #5  0x0000c6e4 in init_display () at dispnew.c:6537
>
> It occurs on the first call to realloc with a non-empty block.  The
> darwin source is hard to follow at this point as malloc blocks are
> controlled in objc code.
>
> Does anyone else see this problem?
> -Steven
>
>
Brad Miller
PhD Candidate
University of Minnesota
(612) 384-8351
http://www-users.cs.umn.edu/~bmiller

Re: Mac OS X 10.2.2 - Need to Recompile

[Steven Tamm]

FWIW, I got it to work by just relinking.  I removed src/emacs and then 
"make"  rerunning make from a two week old version of CVS.

> Now I get a bunch of warnings like this one, chosen at random:
> keyboard.c:62: warning: could not use precompiled header 
> '/usr/include/unistd-gcc3.p', because:
> keyboard.c:62: warning: macro 'select' defined by ./s/darwin.h 
> conflicts with precomp

This warning is OK.  Select is overridden on Mac OS X to deal with a 
small problem when carbon emacs is run from the command line.  It 
should also complain about vfork being overridden.  I don't remember 
what it was for and I'm not sure if that override is necessary in 10.2. 
  If it says "precompiled header is out of date" then run
% sudo fixPrecomps

> Finally the compile dies a horrible death at:
> Compiling /Users/bmiller/src/emacs/lisp/progmodes/cc-mode.el
> >>Error occurred processing 
> /Users/bmiller/src/emacs/lisp/progmodes/cc-mode.el: Symbol's function 
> definition is void ((char-table-p))
> make[1]: *** [compile] Error 1
> make: *** [bootstrap] Error 2

A couple other people have sent this to me.  It appears latest CVS is 
broken.  I just updated to the latest CVS and run a make bootstrap and 
encountered the same problem.  I'm going to try to revert to CVS from 
two weeks ago and see what happens.

Re: Mac OS X 10.2.2 - Need to Recompile

[Andrew Choi]

Brad Miller <bmiller@cs.umn.edu> writes:

> Finally the compile dies a horrible death at:
> Compiling /Users/bmiller/src/emacs/lisp/progmodes/cc-mode.el
>  >>Error occurred processing
>    /Users/bmiller/src/emacs/lisp/progmodes/cc-mode.el: Symbol's
>    function definition is void ((char-table-p))
> make[1]: *** [compile] Error 1
> make: *** [bootstrap] Error 2
> 
> Uggh!  Now I'm really stuck.  Any thoughts on what I can do?

The current CVS code does not bootstrap correctly.  It has already been
reported in gnu.emacs.help.

Re: Mac OS X 10.2.2 - Need to Recompile

[Dan Brotsky]

> I just updated to Mac OS X 10.2.2 and the emacs I was using (compiled
> in 10.2.1) stopped working (similar to the update between 10.1 and
> 10.2).

This is exactly what happened to me.  Unfortunately I don't have a crash
log handy, but as in your case it was a realloc underneath init_display.

Doing a clean recompile (make clean; make) fixed the problem (as you
report happening in your case).

     dan

>   Recompiling fixed everything, so it's not a huge problem.
> Seems that there is a new version of libSystem.B included in 10.2.2,
> which is incompatible.
>
> The error I got was here:
>
> #0  0x90004248 in szone_size ()
> #1  0x000b0b0c in xrealloc (block=0x0, size=321) at alloc.c:542
> #2  0x00006240 in adjust_frame_message_buffer (f=0x63aec0) at
> dispnew.c:2435
> #3  0x00005c20 in adjust_frame_glyphs (f=0x63aec0) at dispnew.c:2133
> #4  0x00005bcc in adjust_frame_glyphs_initially () at dispnew.c:2115
> #5  0x0000c6e4 in init_display () at dispnew.c:6537
>
> It occurs on the first call to realloc with a non-empty block.  The
> darwin source is hard to follow at this point as malloc blocks are
> controlled in objc code.
>
> Does anyone else see this problem?
> -Steven

Re: Mac OS X 10.2.2 - Need to Recompile

[Dan Brotsky]

> I just updated to Mac OS X 10.2.2 and the emacs I was using (compiled
> in 10.2.1) stopped working (similar to the update between 10.1 and
> 10.2).

This is exactly what happened to me.  Unfortunately I don't have a crash
log handy, but as in your case it was a realloc underneath init_display.

Doing a clean recompile (make clean; make) fixed the problem (as you
report happening in your case).

     dan

>   Recompiling fixed everything, so it's not a huge problem.
> Seems that there is a new version of libSystem.B included in 10.2.2,
> which is incompatible.
>
> The error I got was here:
>
> #0  0x90004248 in szone_size ()
> #1  0x000b0b0c in xrealloc (block=0x0, size=321) at alloc.c:542
> #2  0x00006240 in adjust_frame_message_buffer (f=0x63aec0) at
> dispnew.c:2435
> #3  0x00005c20 in adjust_frame_glyphs (f=0x63aec0) at dispnew.c:2133
> #4  0x00005bcc in adjust_frame_glyphs_initially () at dispnew.c:2115
> #5  0x0000c6e4 in init_display () at dispnew.c:6537
>
> It occurs on the first call to realloc with a non-empty block.  The
> darwin source is hard to follow at this point as malloc blocks are
> controlled in objc code.
>
> Does anyone else see this problem?
> -Steven

Re: Mac OS X 10.2.2 - Need to Recompile

[Thorbjørn Ravn Andersen]

Steven Tamm wrote:

> I just updated to Mac OS X 10.2.2 and the emacs I was using (compiled 
> in 10.2.1) stopped working (similar to the update between 10.1 and 
> 10.2).  Recompiling fixed everything, so it's not a huge problem.  
> Seems that there is a new version of libSystem.B included in 10.2.2, 
> which is incompatible.
>
> The error I got was here:
>
> #0  0x90004248 in szone_size ()
> #1  0x000b0b0c in xrealloc (block=0x0, size=321) at alloc.c:542
> #2  0x00006240 in adjust_frame_message_buffer (f=0x63aec0) at 
> dispnew.c:2435
> #3  0x00005c20 in adjust_frame_glyphs (f=0x63aec0) at dispnew.c:2133
> #4  0x00005bcc in adjust_frame_glyphs_initially () at dispnew.c:2115
> #5  0x0000c6e4 in init_display () at dispnew.c:6537
>
> It occurs on the first call to realloc with a non-empty block.  The 
> darwin source is hard to follow at this point as malloc blocks are 
> controlled in objc code.
>
> Does anyone else see this problem?

Yes.  My Emacs did the same.

In gdb with "-nw" the stack trace is as follows:

#0  0x90004248 in szone_size ()
#1  0x000b0e30 in xrealloc (block=0x0, size=481) at alloc.c:542
#2  0x00006240 in adjust_frame_message_buffer (f=0x645ec0) at dispnew.c:2435
#3  0x00005c20 in adjust_frame_glyphs (f=0x645ec0) at dispnew.c:2133
#4  0x00005bcc in adjust_frame_glyphs_initially () at dispnew.c:2115
#5  0x0000c6e4 in init_display () at dispnew.c:6537
#6  0x00061b4c in main (argc=2, argv=0xbffffb98, envp=0x0) at emacs.c:1544
#7  0x000038a8 in _start (argc=50, argv=0x2, envp=0x23b284) at 
/SourceCache/Csu/Csu-45/crt.c:267
#8  0x00003728 in start ()

Then trying to restart with a file name:

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x90013b70 in large_entry_for_pointer_no_lock ()
(gdb) bt
#0  0x90013b70 in large_entry_for_pointer_no_lock ()
#1  0x90004204 in szone_size ()
#2  0x000b0e30 in xrealloc (block=0x0, size=41) at alloc.c:542
#3  0x00006240 in adjust_frame_message_buffer (f=0x645ec0) at dispnew.c:2435
#4  0x00005c20 in adjust_frame_glyphs (f=0x645ec0) at dispnew.c:2133
#5  0x00005bcc in adjust_frame_glyphs_initially () at dispnew.c:2115
#6  0x00061b4c in main (argc=2, argv=0xbffffb98, envp=0x646) at emacs.c:1544
#7  0x000038a8 in _start (argc=50, argv=0x2, envp=0x23b284) at 
/SourceCache/Csu/Csu-45/crt.c:267
#8  0x00003728 in start ()

I'll save this binary if you need me to do additional testing.




-- 
  Thorbjørn Ravn Andersen      Scandiatransplant
                               Skejby Sygehus, indgang 3
  +45 89 49 53 01              DK-8200 Århus N
  http://biobase.dk/~tra         

Re: Mac OS X 10.2.2 - Need to Recompile

[Richard Stallman]

    I just updated to Mac OS X 10.2.2 and the emacs I was using (compiled 
    in 10.2.1) stopped working (similar to the update between 10.1 and 
    10.2).  Recompiling fixed everything, so it's not a huge problem.  

Could you write a note for etc/PROBLEMS?
If you can fix the problem, that is good, but not desperately
necessary; however, it is important to have that note.

Re: Mac OS X 10.2.2 - Need to Recompile

[Steven Tamm]

Done.  Here it is.

* Emacs crashes on Mac OS X (Carbon) after system software upgrade.

Between Mac OS X release 10.2.1 and 10.2.2 there was an incompatible
change in the memory allocator that causes a EXC_BAD_ACCESS error near
xrealloc().  Relinking the application (by deleting src/temacs and
running make) will solve the problem.  It appears to be caused by some
problems with the unexec code and its interaction with libSystem.B.

-----

I researched the problem and it appears to be related to the 
unexmacosx.c code.   I need to compare more the unexdyld.c code from 
apple (which provided an upwardly compatibly release) with how 
unexmacosx works.  Hopefully darwin will get a little more stable so 
that the incompatible changes won't happen so frequently.

For those who still have a bad binary, could you check to see if 
setting the environment variable DYLD_FORCE_FLAT_NAMESPACE fixes 
anything?  I have a sneaky suspicion it might; but it could also fail 
due to redefinition of some terminfo variables BC, PC, and UP.

-Steven

P.S.  I spent a little bit of time trying to get unexdyld.c to work 
with the Carbon GUI.  As Andrew's comments in unexmacosx.c explain, the 
use of malloc_freezedry and malloc_jumpstart exist in 
Next/Openstep/rhapsody/darwin solely for the purpose of emacs unexec.  
However, it appears that any use of the CoreFoundtation layer (which 
Carbon uses extensively) causes malloc_freezedry to break.  The 
unexmacosx.c code does pretty much the same thing that freezedry does, 
but with a finer degree of control by using the primitives in 
scaleable_malloc directly.  However, if you try to update_prebinding on 
an emacs binary, it complains that hints table is out of place.  
Running  otool -l on the Apple provided binary next to one from CVS 
yields a very, very different story.   More investigation into this is 
needed.

On Wednesday, November 13, 2002, at 03:33  AM, Richard Stallman wrote:

>     I just updated to Mac OS X 10.2.2 and the emacs I was using 
> (compiled
>     in 10.2.1) stopped working (similar to the update between 10.1 and
>     10.2).  Recompiling fixed everything, so it's not a huge problem.
>
> Could you write a note for etc/PROBLEMS?
> If you can fix the problem, that is good, but not desperately
> necessary; however, it is important to have that note.
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Mac OS X 10.2.2 - Need to Recompile

[Mikael Krantz]

On Thu, 14 Nov 2002, Steven Tamm wrote:
> For those who still have a bad binary, could you check to see if 
> setting the environment variable DYLD_FORCE_FLAT_NAMESPACE fixes 
> anything?  I have a sneaky suspicion it might; but it could also fail 
> due to redefinition of some terminfo variables BC, PC, and UP.

Well, it fixes something... at least now it breaks in another way (due to 
redefinition of BC it seems). 

More info:

I've tried to bootstrap from CVS (latest, 2002-11-01 and 2002-09-27) with
similar results:

make bootstrap fails with:
    ../src/bootstrap-emacs -batch --no-site-file --multibyte -l autoload 
    --eval '(setq generated-autoload-file "/Users/mk/emacs/lisp/loaddefs.el")' 
    -f batch-update-autoloads $wins
    Directories: /Users/mk/emacs/lisp /Users/mk/emacs/lisp/calc 
    /Users/mk/emacs/lisp/calendar /Users/mk/emacs/lisp/emacs-lisp 
    /Users/mk/emacs/lisp/emulation /Users/mk/emacs/lisp/eshell 
    /Users/mk/emacs/lisp/gnus /Users/mk/emacs/lisp/international 
    /Users/mk/emacs/lisp/language /Users/mk/emacs/lisp/mail 
    /Users/mk/emacs/lisp/net /Users/mk/emacs/lisp/obsolete 
    /Users/mk/emacs/lisp/play /Users/mk/emacs/lisp/progmodes 
    /Users/mk/emacs/lisp/term /Users/mk/emacs/lisp/textmodes 
    /Users/mk/emacs/lisp/toolbar
    make[1]: *** [autoloads] Error 139
    make: *** [bootstrap] Error 2

closer examination (gdb) yields that bootstrap-emacs segfaults when 
initializing dyld:
    (gdb) run 
    Starting program: /Users/mk/emacs/src/bootstrap-emacs 
    [Switching to process 7017 thread 0xb03]
    Reading symbols for shared libraries 
    ................................................. done

    Program received signal EXC_BAD_ACCESS, Could not access memory.
    0x8fe0d53c in __dyld_lookup_symbol ()
    (gdb) bt
    #0  0x8fe0d53c in __dyld_lookup_symbol ()
    #1  0x8fe0baac in __dyld_resolve_undefineds ()
    #2  0x8fe10614 in __dyld_link_in_need_modules ()
    #3  0x8fe014e4 in __dyld__dyld_init ()
    (gdb) 

If I define DYLD_FORCE_FLAT_NAMESPACE it fails with:
    bash-2.05$ env DYLD_FORCE_FLAT_NAMESPACE= src/bootstrap-emacs 
    dyld: src/bootstrap-emacs multiple definitions of symbol _BC
    src/bootstrap-emacs definition of _BC
    /usr/lib/libncurses.5.dylib(lib_termcap.o) definition of _BC
    Trace/BPT trap
As you suspected.

I'm using 10.2.2 with latest developer tools (gcc 3.1).

/Mikael Krantz

Re: Mac OS X 10.2.2 - Need to Recompile

[Mikael Krantz]

On Fri, 15 Nov 2002, Mikael Krantz wrote:

> On Thu, 14 Nov 2002, Steven Tamm wrote:
> > For those who still have a bad binary, could you check to see if 
> > setting the environment variable DYLD_FORCE_FLAT_NAMESPACE fixes 
> > anything?  I have a sneaky suspicion it might; but it could also fail 
> > due to redefinition of some terminfo variables BC, PC, and UP.
> 
> Well, it fixes something... at least now it breaks in another way (due to 
> redefinition of BC it seems). 
> 
> More info:
> 
> I've tried to bootstrap from CVS (latest, 2002-11-01 and 2002-09-27) with
> similar results:
> ...
> closer examination (gdb) yields that bootstrap-emacs segfaults when 
> initializing dyld:

It seems that there was a problem with MacOS X rather than emacs itself. 
Doing a "Repair permissions" in Discutil followed by a reboot made it go 
away. 

DYLD_FORCE_FLAT_NAMESPACE still fails, though the binary runs fine without 
it :)

Sorry for any confusion I may have caused.

/Mikael Krantz

Re: Mac OS X 10.2.2 - Need to Recompile

[Thorbjørn Ravn Andersen]

Steven Tamm wrote:

>
> For those who still have a bad binary, could you check to see if 
> setting the environment variable DYLD_FORCE_FLAT_NAMESPACE fixes 
> anything?  I have a sneaky suspicion it might; but it could also fail 
> due to redefinition of some terminfo variables BC, PC, and UP.
>
For me the following happens:

[sc147:~] ravn% setenv DYLD_FORCE_FLAT_NAMESPACE
[sc147:~] ravn% /usr/local/bin/emacs-21.3.50.crashes-under-1022
dyld: /usr/local/bin/emacs-21.3.50.crashes-under-1022 multiple 
definitions of symbol _BC
/usr/local/bin/emacs-21.3.50.crashes-under-1022 definition of _BC
/usr/lib/libncurses.5.dylib(lib_termcap.o) definition of _BC
Trace/BPT trap
[sc147:~] ravn% unsetenv DYLD_FORCE_FLAT_NAMESPACE
[sc147:~] ravn% /usr/local/bin/emacs-21.3.50.crashes-under-1022
Fatal error (11).Segmentation fault
[sc147:~] ravn%

-- 
  Thorbjørn Ravn Andersen      Scandiatransplant
                               Skejby Sygehus, indgang 3
  +45 89 49 53 01              DK-8200 Århus N
  http://biobase.dk/~tra