Peter N Lewis wrote,

Does anyone have any idea what this means:

#### #### FDE 0x2aea4 (OB 0x13fd60, fde_end 0x2affc) has zero length!Aborting. #### Abort

I am trying to use the Authorization code with GPC. If I write the code in C, it works fine. If I write the code in GPC, it works unless the user cancels the authorization dialog, in which case it gets the above error.

I'm running out of ideas as to what the problem might be.

I found this reference:

Index: unwind-dw2-fde.c

RCS file: /cvs/Darwin/src/live/gcc3/gcc/unwind-dw2-fde.c,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- unwind-dw2-fde.c 2002/09/10 20:53:31 1.30 +++ unwind-dw2-fde.c 2002/11/07 20:33:20 1.31 @ @-1,5 +1,5 @ @ /* Subroutines needed for unwinding stack frames for exception handling. */ -/* Copyright (C) 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc. +/* Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc. Contributed by Jason Merrill <jason@ cygnus.com>.

This file is part of GCC. @ @-38,203 +38,7 @ @#include "unwind-dw2-fde.h" #include "gthr.h" #endif -/* APPLE LOCAL declare string functions */ -#include <string.h>

-/* APPLE LOCAL begin fde end extension */ -#ifdef DWARF2_OBJECT_END_PTR_EXTENSION -static inline int VALID_FDE_P(struct object *OB, struct dwarf_fde *FDE) -{

• if ((char *)FDE < OB->dwarf_fde_end)
• {

•  if (FDE->length <= 0)
  

• {
  

•   printf ("####\n#### FDE %p (OB %p, fde_end %p) has zero 
  

length!"

•           "Aborting.\n####\n", FDE, OB, OB->dwarf_fde_end);
  

•   abort();
  

• }
  

•  else
  

• return 1;
  

• }
• return 0;

-} -#else -#define VALID_FDE_P(OB, FDE) ((FDE)->length != 0) -#endif -/* APPLE LOCAL end fde end extension */

Which seems to indicate that the code has been removed from gcc and it is related to unwiding the stack somehow, perhaps exception handling?

It's possible I've badly translated the Authorization[Tags].h files, but I'm getting a bit desperate for an idea on where the problem might lie, so if anyone has any clues, that'd be appreciated.

After a lot af experimenting, we found that the problem was related to linking-in libgpc.a and/or large parts libgcc.a. Peter finally asked the maintainers of the gcc-exception handling code:

I am trying to track down a problem we are experiencing with GNU Pascal/Mac OS X. Specifically, when the Mac OS X authorization system is called to ask for the administrator password, and the cancel button is pressed, instead of returning normally with an error, the program is aborted with the following message:

#### #### FDE 0x2aea4 (OB 0x140880, fde_end 0x2affc) has zero length!Aborting. #### Abort

Similar programs compiled in gcc do not have this problem. As near as I can understand it, the authorization system is throwing an exception, and instead of it being caught as normal, the exception system is detecting an error condition and aborting the program. The problem seems to be the existence of some DWARF "object" that has a negative FDE length. I don't actually know what that last sentence really means though.

Is there any light you could shed on this issue to help us figure out what GNU Pascal might be doing that could induce this error?

Thanks, Peter.

The answer came from Geoffrey Keating:

You have out-of-date exception handling support (libgcc.a and crt2.o). Try upgrading the base compiler to GCC 3.3.

Peter N Lewis wrote:

Would this problem likely be fixed with GCC 3.3 even if the authorization code in the system remains as it is?

Geoffrey Keating wrote:

Yes, if you upgrade the compiler that's part of GNU Pascal to GCC 3.3, GNU Pascal will stop producing the invalid exception-handling layout.

My conclusion is that Apple has patched-gcc exception handling in its own version of gcc, used to compile the system software that causes the exception. The patch is not compatible with fsf-gcc-3.2.x but will be compatible with fsf-gcc-3.3. Many Apple-specific gcc-patches are now being merged into standard-fsf-gcc. For example, Apple has donated precompiled header support that will be part of fsf-gcc-3.4. The merge is good news, as it enables us to stay with fsf-gcc for the Mac OS X port of gpc.

Regards,

Adriaan van Os