gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Re: Large GCL Configurations


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: Large GCL Configurations
Date: 13 Apr 2004 10:13:59 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

Aurelien Chanudet <address@hidden> writes:

> > Greetings, and thanks for your feedback!  Aurelien, the CPPFLAG does
> > not appear to be completely propagated to the bfd/libiberty subbuild.
> > Have you seen this before?  Is this a question of libtools or some
> > such mismatch with what you are runninng?
> 
> This isn't something I've seen before. Nor does it is, in my opinion,
> a question of libtools or the like. All these environment variables
> are defined in my ~/.bashrc file, so that I don't really care when to
> set them.
> 

OK, then we definitely have a mystery with Warren's results.

> > Why is this flag necessary?
> > Can't we use GNU cpp on GNU header files when fink is available?
> 
> Apple has its own preprocessor. While it might occasionally deliver
> speed improvement, this preprocessor isn't compatible with most
> traditional C source files. For this reason, I'm always deactivating
> it : this is the purpose of CPPFLAGS="-no-cpp-precomp". Now, I suspect
> that deactivating Apple's custom preprocessor means replacing it by
> the default GNU (?) preprocessor.
> 

Would it not also be possible to explicitly designate GNU cpp via PATH
settings and the like?

> > I'd like to figure out why this doesn't work out of the box like it
> > does on Aurelien's system if possible.
> 
> But before we fix this, I've found out the latest 2.6.1 errors out on
> MacOS X when the first memory allocation is to take place. It seems
> pretty straightforward to identify where the error is originating
> from, but I'm unsure about how to fix it : apparently, the very first
> memory allocation fails because GBC isn't enabled (which yields an
> "Error: Caught fatal error [memory may be damaged]" when run outside
> of gdb). Any idea ?
> 
> Starting program: /src/src/gcl-2.6.1/unixport/saved_pre_gcl
> 

GBC_enable is explicitly turned off at the point in main where you are
setting up your sigstack with malloc.  May I suggest that you use a
static buffer instead of malloc, like the default code following the
ifdef SETUP_SIG_STACK in main, e.g.:

#ifdef SETJMP_ONE_DIRECTION
            static
#endif
            double estack_buf[SIG_STACK_SIZE];
            
...

What I'm wondering is -- how did this ever work?

Take care,


> Breakpoint 1, alloc_contblock (n=131072) at alloc.c:538
> 538             g = FALSE;
> (gdb) c
> Continuing.
> 
> Breakpoint 2, alloc_contblock (n=131072) at alloc.c:558
> 558                     if (!g)
> (gdb) n
> 559                       GBC(t_contiguous);
> (gdb) s
> GBC (t=t_contiguous) at gbc.c:1067
> 1067      int in_sgc = sgc_enabled;
> (gdb) n
> 1070      int tm=0;
> (gdb) n
> 1073      if (in_signal_handler && t == t_relocatable)
> (gdb) n
> 1076      if (GBC_enter_hook != NULL)
> (gdb) n
> 1079      if (!GBC_enable)
> (gdb) n
> 1080        error("GBC is not enabled");
> (gdb) bt
> #0  GBC (t=t_contiguous) at gbc.c:1080
> #1  0x0001c7d0 in alloc_contblock (n=131072) at alloc.c:559
> #2  0x0001fba0 in my_malloc (size=131072) at alloc.c:1413
> #3  0x00002e04 in main (argc=1, argv=0xbffffc38, envp=0xbffffc40) at
> main.c:285
> (gdb) c
> Continuing.
> 
> Error: Caught fatal error [memory may be damaged]
> Error signalled by an anonymous function.
> Broken at COND.  Type :H for Help.
>  >>
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]