MacOSX emacs crashes after 10.4.3 update

MacOSX emacs crashes after 10.4.3 update

[Ken Raeburn]

I have an EmacsInstaller.dmg that I built on Sep 23, which installed  
an Emacs.app that worked just fine, up until earlier today when I  
updated my OS from 10.4.2 to 10.4.3.  It was built with mac/make- 
package, I think with defaults except for telling it to build a self- 
contained app.  Now it crashes at startup, and the CrashReporter log  
can't even give me a stack trace:

Command: Emacs
Path:    /Applications/Emacs.app/Contents/MacOS/Emacs
Parent:  WindowServer.orig [115]

Version: 22.0.50 (1.1)

PID:    429
Thread: 0

Exception:  EXC_BAD_INSTRUCTION (0x0002)
Code[0]:    0x00000002
Code[1]:    0x03802458


Thread 0 Crashed:
[stack trace should normally be here, but nothing shown]

Thread 0 crashed with PPC Thread State 64:
   srr0: 0x0000000003802458 srr1:  
0x000000000208f930                        vrsave: 0x0000000000000000
     cr: 0x24842488          xer: 0x0000000000000004   lr:  
0x000000000380245b  ctr: 0x0000000090014560
     r0: 0x000000000380245b   r1: 0x00000000bfffed90   r2:  
0x00000000002545e0   r3: 0x0000000000000000
     r4: 0x0000000000000000   r5: 0x0000000000000002   r6:  
0x0000000000002564   r7: 0x0000000000000000
     r8: 0x000000000482e1e6   r9: 0x00000000bfffe14f  r10:  
0x0000000000000000  r11: 0x00000000a0006234
    r12: 0x0000000090014560  r13: 0x00000000bfffe240  r14:  
0x0000000000000002  r15: 0x00000000bfffe1c0
    r16: 0x0000000000000001  r17: 0x000000000482e1fa  r18:  
0x0000000000000000  r19: 0x00000000bfffe3c0
    r20: 0x00000000bfffe140  r21: 0x000000000482e1d8  r22:  
0x000000000000000e  r23: 0x000000005605f000
    r24: 0x00000000bfffedd0  r25: 0x000000000028e600  r26:  
0x00000000002c4eb0  r27: 0x00000000000b9ac0
    r28: 0x0000000000114a30  r29: 0x0000000044008224  r30:  
0x00000000000c61c0  r31: 0x00000000001b3e51

Binary Images Description:
     0x1000 -   0x172fff org.gnu.Emacs 22.0.50 (1.1)	/Applications/ 
Emacs.app/Contents/MacOS/Emacs
0x8fe00000 - 0x8fe54fff dyld 44.2	/usr/lib/dyld
0x90000000 - 0x901b3fff libSystem.B.dylib 	/usr/lib/libSystem.B.dylib
0x9020b000 - 0x9020ffff libmathCommon.A.dylib 	/usr/lib/system/ 
libmathCommon.A.dylib
[...]

(The WindowServer.orig bit is just a hack that raises the per-user  
process limit before running the WindowServer binary.)

I think I've seen something like this a couple of times before -- an  
installed Emacs.app suddenly no longer working, I think generally  
coinciding with an OS update.  Reinstalling Emacs from the  
EmacsInstaller doesn't help, but (when I've run into this before)  
rebuilding Emacs fixes it.  Could the installed Emacs binary be too  
OS-version (or shared-library-version) dependent?

If I run ..../Contents/MacOS/bin/emacs from the shell, I get a bus  
error; gdb reports:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x60001178
0x900fe478 in __grow_type_table ()
(gdb) bt
#0  0x900fe478 in __grow_type_table ()
#1  0x00122ff8 in init_callproc () at /Users/raeburn/Desktop/dev/ 
emacs/mac/../src/callproc.c:1586
#2  0x0007915c in main (argc=400, argv=0xbffff7bc) at /Users/raeburn/ 
Desktop/dev/emacs/mac/../src/emacs.c:1532
(gdb)


Is there anything more I can do to help track this down?  I've got  
another Mac at work that is still at 10.4.2.  Nothing in the  
changelog since 2005-09-23 really jumps out at me as likely to fix  
this, but I'm updating my sources anyways and will try another 10.4.2  
build and see if it works on 10.4.3.

Ken

Re: MacOSX emacs crashes after 10.4.3 update

[David Reitter]

[-- Attachment #1.1: Type: text/plain, Size: 1010 bytes --]

On 4 Nov 2005, at 19:38, Ken Raeburn wrote:

> I have an EmacsInstaller.dmg that I built on Sep 23, which  
> installed an Emacs.app that worked just fine, up until earlier  
> today when I updated my OS from 10.4.2 to 10.4.3.  It was built  
> with mac/make-package, I think with defaults except for telling it  
> to build a self-contained app.  Now it crashes at startup, and the  
> CrashReporter log can't even give me a stack trace:

This is unfortunate, but seems to be a known problem. Similarly,  
binaries built on 10.4 generally don't run on 10.3.

The Mac port contains a lot of code to support ancient systems /  
system APIs like MacOS 8/9, apparently even without CarbonLib (never  
tried, though), but there is pretty much no binary compatibility  
between OS versions for Emacs.

Have you tried setting the environment variable  
MACOSX_DEPLOYMENT_TARGET=10.4 ?
E.g.

MACOSX_DEPLOYMENT_TARGET=10.4 ./make-package (...)

I heard that helps you build binaries that run on all 10.4 versions.





[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2400 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: MacOSX emacs crashes after 10.4.3 update

[Ken Raeburn]

On Nov 4, 2005, at 15:14, David Reitter wrote:
> On 4 Nov 2005, at 19:38, Ken Raeburn wrote:
> This is unfortunate, but seems to be a known problem. Similarly,  
> binaries built on 10.4 generally don't run on 10.3.
>
> The Mac port contains a lot of code to support ancient systems /  
> system APIs like MacOS 8/9, apparently even without CarbonLib  
> (never tried, though), but there is pretty much no binary  
> compatibility between OS versions for Emacs.

Hmm, very sad.

> Have you tried setting the environment variable  
> MACOSX_DEPLOYMENT_TARGET=10.4 ?
> E.g.
>
> MACOSX_DEPLOYMENT_TARGET=10.4 ./make-package (...)
>
> I heard that helps you build binaries that run on all 10.4 versions.

Yes, the installer I built this way on 10.4.2 seems to give me an  
Emacs.app that works fine on 10.4.3.  Thanks.

Maybe that should be automatic?  Or at least documented in the mac/*  
files...

Ken

Re: MacOSX emacs crashes after 10.4.3 update

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 4 Nov 2005 20:14:30 +0000, David Reitter <david.reitter@gmail.com> said:

> This is unfortunate, but seems to be a known problem. Similarly,
> binaries built on 10.4 generally don't run on 10.3.

> The Mac port contains a lot of code to support ancient systems /
> system APIs like MacOS 8/9, apparently even without CarbonLib (never
> tried, though), but there is pretty much no binary compatibility
> between OS versions for Emacs.

Does this affect all the Mac binaries including X11, or Carbon port
only?

> Have you tried setting the environment variable
> MACOSX_DEPLOYMENT_TARGET=10.4 ?  E.g.

> MACOSX_DEPLOYMENT_TARGET=10.4 ./make-package (...)

> I heard that helps you build binaries that run on all 10.4 versions.

Do you have any references explaining why it works (or why binary
compatibility is broken without it)?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: MacOSX emacs crashes after 10.4.3 update

[Brad Howes]

On Nov 5, 2005, at 6:59 AM, YAMAMOTO Mitsuharu wrote:

> Does this affect all the Mac binaries including X11, or Carbon port
> only?

My experience has been that any time the version number changes, I've  
had to at least regenerate an emacs executable. To be safe, now I  
just reconfigure, make, and install.

Brad

Re: MacOSX emacs crashes after 10.4.3 update

[David Reitter]

[-- Attachment #1.1: Type: text/plain, Size: 1072 bytes --]

On 5 Nov 2005, at 11:59, YAMAMOTO Mitsuharu wrote:

>> Have you tried setting the environment variable
>> MACOSX_DEPLOYMENT_TARGET=10.4 ?  E.g.
>
>> MACOSX_DEPLOYMENT_TARGET=10.4 ./make-package (...)
>
>> I heard that helps you build binaries that run on all 10.4 versions.
>
> Do you have any references explaining why it works (or why binary
> compatibility is broken without it)?

Not sure.

This technote seems to apply:

http://developer.apple.com/technotes/tn2002/tn2064.html

What I gather from that document:

MACOSX_DEPLOYMENT_TARGET is a linker flag, and without it being set  
to at least 10.2, the linker doesn't seem to do "weak linking", that  
is, it'll always statically bind to the libraries present on the  
build system.
Code that imports symbols may need to set a weak_import flag set as  
follows:

	extern int SayHello() __attribute__((weak_import));

The code doesn't currently seem to use it.

MACOSX_DEPLOYMENT_TARGET probably does more than that. Maybe it would  
be worth setting MACOSX_DEPLOYMENT_TARGET to 10.3 and build on a 10.4  
machine.


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2400 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: MacOSX emacs crashes after 10.4.3 update

[Ken Raeburn]

On Nov 5, 2005, at 09:17, David Reitter wrote:
> This technote seems to apply:
>
> http://developer.apple.com/technotes/tn2002/tn2064.html

> MACOSX_DEPLOYMENT_TARGET probably does more than that. Maybe it  
> would be worth setting MACOSX_DEPLOYMENT_TARGET to 10.3 and build  
> on a 10.4 machine.

A coworker of mine was explaining to me yesterday about the  
availability macros (described in that tech note) and how the compile- 
time settings are derived from the environment variable.  So, yes,  
it'll affect compilation as well as linking...

Ken

Re: MacOSX emacs crashes after 10.4.3 update

[Piet van Oostrum]

>>>>> Ken Raeburn <raeburn@raeburn.org> (KR) wrote:

>KR> I have an EmacsInstaller.dmg that I built on Sep 23, which installed  an
>KR> Emacs.app that worked just fine, up until earlier today when I  updated my
>KR> OS from 10.4.2 to 10.4.3.  It was built with mac/make- 
>KR> package, I think with defaults except for telling it to build a self- 
>KR> contained app.  Now it crashes at startup, and the CrashReporter log  can't
>KR> even give me a stack trace:

I have one built on Oct 28 on 10.4 and it runs without problems thus far.
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: piet@vanoostrum.org

Re: MacOSX emacs crashes after 10.4.3 update

[Seiji Zenitani]

Yamamoto-san,



> > Have you tried setting the environment variable
> > MACOSX_DEPLOYMENT_TARGET=10.4 ?  E.g.
>
> > MACOSX_DEPLOYMENT_TARGET=10.4 ./make-package (...)
>
> > I heard that helps you build binaries that run on all 10.4 versions.
>
> Do you have any references explaining why it works (or why binary
> compatibility is broken without it)?

I hope Nozomu Ando-san's description (in Japanese language) will be  
helpful.

http://homepage.mac.com/nand/macosx/emacs_cross.html



--

Seiji Zenitani

zenitani@mac.com

Re: MacOSX emacs crashes after 10.4.3 update

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 6 Nov 2005 16:46:45 +0900, Seiji Zenitani <zenitani@mac.com> said:

> Yamamoto-san,
>> > Have you tried setting the environment variable >
>> MACOSX_DEPLOYMENT_TARGET=10.4 ?  E.g.
>> 
>> > MACOSX_DEPLOYMENT_TARGET=10.4 ./make-package (...)
>> 
>> > I heard that helps you build binaries that run on all 10.4
>> versions.
>> 
>> Do you have any references explaining why it works (or why binary
>> compatibility is broken without it)?

> I hope Nozomu Ando-san's description (in Japanese language) will be
> helpful.

> http://homepage.mac.com/nand/macosx/emacs_cross.html

Thanks for the info.  He says "MACOSX_DEPLOYMENT_TARGET=10.4 ..." is
not a fix but a workaround.

I'm very new to Tiger and I just started using it after the 10.4.3
release, but now I think I understand the situation.  This is not a
Carbon-specific issue, but every build on Mac OS X 10.4/Darwin 8 PPC
is affected.

  http://darwinsource.opendarwin.org/10.4.3/xnu-792.6.22/bsd/sys/cdefs.h
  (about "long double compatibility")

  http://darwinsource.opendarwin.org/10.4.3/SystemStubs-5/

Ironically, this mechanism seems to be introduced for binary
compatibility.

Ando-san, what do you think about the following change?  It clears a
part of the __bss section on unexec, where the cleared part is located
after the static uninitialized variables in the Emacs source.  I tried
to make an executable on 10.4.3 (linked with libncurses.5.dynlib),
then it could be executed on 10.3.9.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/unexmacosx.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/unexmacosx.c,v
retrieving revision 1.15
diff -c -r1.15 unexmacosx.c
*** src/unexmacosx.c	7 Aug 2005 12:33:18 -0000	1.15
--- src/unexmacosx.c	8 Nov 2005 00:44:25 -0000
***************
*** 193,198 ****
--- 193,221 ----
    return write (outfd, src, count) == count;
  }
  
+ /* Clear n bytes in outfd starting at offset dest.  Return true if
+    successful, false otherwise.  */
+ static int
+ unexec_clear (off_t dest, size_t count)
+ {
+   char buf[UNEXEC_COPY_BUFSZ];
+   ssize_t bytes;
+ 
+   bzero (buf, UNEXEC_COPY_BUFSZ);
+   if (lseek (outfd, dest, SEEK_SET) != dest)
+     return 0;
+ 
+   while (count > 0)
+     {
+       bytes = count > UNEXEC_COPY_BUFSZ ? UNEXEC_COPY_BUFSZ : count;
+       if (write (outfd, buf, bytes) != bytes)
+ 	return 0;
+       count -= bytes;
+     }
+ 
+   return 1;
+ }
+ 
  /* Copy n bytes from starting offset src in infd to starting offset
     dest in outfd.  Return true if successful, false otherwise.  */
  static int
***************
*** 684,697 ****
  	  if (!unexec_write (header_offset, sectp, sizeof (struct section)))
  	    unexec_error ("cannot write section %s's header", SECT_DATA);
  	}
!       else if (strncmp (sectp->sectname, SECT_BSS, 16) == 0
! 	       || strncmp (sectp->sectname, SECT_COMMON, 16) == 0)
  	{
  	  sectp->flags = S_REGULAR;
  	  if (!unexec_write (sectp->offset, (void *) sectp->addr, sectp->size))
! 	    unexec_error ("cannot write section %s", SECT_DATA);
  	  if (!unexec_write (header_offset, sectp, sizeof (struct section)))
! 	    unexec_error ("cannot write section %s's header", SECT_DATA);
  	}
        else if (strncmp (sectp->sectname, "__la_symbol_ptr", 16) == 0
  	       || strncmp (sectp->sectname, "__nl_symbol_ptr", 16) == 0
--- 707,737 ----
  	  if (!unexec_write (header_offset, sectp, sizeof (struct section)))
  	    unexec_error ("cannot write section %s's header", SECT_DATA);
  	}
!       else if (strncmp (sectp->sectname, SECT_COMMON, 16) == 0)
  	{
  	  sectp->flags = S_REGULAR;
  	  if (!unexec_write (sectp->offset, (void *) sectp->addr, sectp->size))
! 	    unexec_error ("cannot write section %s", SECT_COMMON);
  	  if (!unexec_write (header_offset, sectp, sizeof (struct section)))
! 	    unexec_error ("cannot write section %s's header", SECT_COMMON);
! 	}
!       else if (strncmp (sectp->sectname, SECT_BSS, 16) == 0)
! 	{
! 	  extern char *my_endbss_static;
! 	  unsigned long my_end = (unsigned long)my_endbss_static;
! 
! 	  assert (sectp->addr <= my_end
! 		  && my_end <= sectp->addr + sectp->size);
! 
! 	  sectp->flags = S_REGULAR;
! 	  if (!unexec_write (sectp->offset, (void *) sectp->addr,
! 			     my_end - sectp->addr))
! 	    unexec_error ("cannot write section %s", SECT_BSS);
! 	  if (!unexec_clear (sectp->offset + (my_end - sectp->addr),
! 			     sectp->size - (my_end - sectp->addr)))
! 	    unexec_error ("cannot write section %s", SECT_BSS);
! 	  if (!unexec_write (header_offset, sectp, sizeof (struct section)))
! 	    unexec_error ("cannot write section %s's header", SECT_BSS);
  	}
        else if (strncmp (sectp->sectname, "__la_symbol_ptr", 16) == 0
  	       || strncmp (sectp->sectname, "__nl_symbol_ptr", 16) == 0

Re: MacOSX emacs crashes after 10.4.3 update

[nand]

On Nov 8, 2005, at 10:18 AM, YAMAMOTO Mitsuharu wrote:
> Ando-san, what do you think about the following change?  It clears a
> part of the __bss section on unexec, where the cleared part is located
> after the static uninitialized variables in the Emacs source.

I'm sorry that I myself don't have enough time to test this code,
but with looking through the code, I think it's OK.

Thanks,

Nozomu Ando

Re: MacOSX emacs crashes after 10.4.3 update

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 8 Nov 2005 15:29:17 +0900, nand <nand@mac.com> said:

> On Nov 8, 2005, at 10:18 AM, YAMAMOTO Mitsuharu wrote:
>> Ando-san, what do you think about the following change?  It clears
>> a part of the __bss section on unexec, where the cleared part is
>> located after the static uninitialized variables in the Emacs
>> source.

> I'm sorry that I myself don't have enough time to test this code,
> but with looking through the code, I think it's OK.

Thanks.  I've just installed the change.

I happen to have a chance to test Mac OS X 10.4.0 as well as 10.4.3,
and binary compatibility was preserved in both directions.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp