gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] trying to finalize the windows issues ...


From: Camm Maguire
Subject: Re: [Gcl-devel] trying to finalize the windows issues ...
Date: 27 May 2004 16:19:39 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

"Mike Thomas" <address@hidden> writes:

> Hi there.
> 
> Per Camm's earlier suggestion:
> 
> | | 2) more than 65k C stack, -> 8mb)  re: the maxima
> | | ignore-errors issue with --enable-debug and let me know what the
> | | status is?
> |
> | This is an interesting suggestion which showed up weaknesses in
> | the Windows NULL_OR_ON_C_STACK system (see below).  So far I have
> | only matched the test to the default 2Mb stack.  Perhaps raising
> | the stack to 8Mb will help?  Can't get to it today unfortunately.
> 
> Some progress to report with an 8M C stack:
> 
> On a --enable-debug build using gcc 3.3.1 and friends and with an 8M stack
> hack the Maxima ignore-errors bug did not manifest and a HEAD branch random
> tester (from a couple of weeks ago) ran for 1000 iterations.
> 
> Building without --enable-debug led to the same result on Maxima, but I
> foolishly  updated the HEAD random tester before running in optimised mode
> only to discover that it no longer compiles with 2.6.1 GCL due to:
> 

I assume you mean here that with 3.3.1 and 8M stack, no ignore-errors
bug in maxima with or without optimization.

One way to figure out if this is luck or real is to verify that the
error elimination persists for values above 8M, and is reintroduced
for some value between 8 and 2 M.

On BSD like systems, there is a setrlimit/getrlimit pair of system
calls.  One can limit the stack and trigger a segfault on an attempted
function call which would push the stack pointer out of bounds.  Does
such exist on mingw?

How are you increasing the stack?  Are you changing _stacktop and
_stackbottom?  Are you adding gcc flags (i.e. --stack below)?  What is
the natural stack limit be default on mingw?  Do you have a ulimit -a
shell command?

> ==========================================================================
> gcc: --stack=8388608: linker input file unused because linking not done
> OPTIMIZE levels: Safety=3, Space=0, Speed=3
> Finished compiling ansi-aux.lsp.
> Loading ansi-aux.o
> Error in PCL::LOAD-DEFMETHOD [or a callee]: No class named: RANDOM-STATE.
> ==========================================================================
> 
> However, reverting to version 1.95 of that file avoided that problem.
> Unfortunately the optimised compile crash in universe.lsp is still there:
> 
> ==========================================================================
> OPTIMIZE levels: Safety=3, Space=0, Speed=3
> Finished compiling ansi-aux-macros.lsp.
> Loading ansi-aux-macros.o
> start address -T 107f0680 Finished loading ansi-aux-macros.o
> Loading universe.lsp
> 
> Unrecoverable error: Segmentation violation..
> 
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
> make: *** [mike-test] Error 3
> ==========================================================================

This one should be backtraceable, no?  Have you already sent me one on
this, i.e. with -g -O?, where '?' is the minimum opt flag causing the
crash?  This is gone with no opt on, right?

> 
> I am proceeding to try with gcc 3.4.0 to see whether the optimised randowm
> tester compiler failure goes away.
> 
> Either way with minor mods to the Windows stack via the compiler options I
> am hoping Camm's new 2.6.2 will at least cover the main test bases if built
> using --enable-debug.
> 
> I'm wary as I don't understand how a short C stack would have caused the
> ignore-errors path handling failure - the test passes may just be good luck.


Well, to my understanding the default marking algorithm won't traverse
the C stack properly, hence mark_c_stack_carefully, as in the comment:

static void
mark_object(object x) {
  
  long i;
  int j;
  object *p;
  char *cp;
  
  cs_check(x);
 BEGIN:
  /* if the body of x is in the c stack, its elements
     are marked anyway by the c stack mark carefully, and
     if this x is somehow hanging around in a cons that
     should be dead, we dont want to mark it. -wfs
  */
  
  if (NULL_OR_ON_C_STACK(x))


Furthermore, one absolutely needs to ensure that the heap and the
stack don't collide, but this should be checked for in the snippet
involving NULL_OR_ON_C_STACK in main.c at startup.  

I'll try to go over your sbrk emulation just in case there could be a
clue in there -- does this sound possible?  Also, it would be great at
one point to have one sbrk emulation layer shared between windows and
macosx. 

Take care,

> 
> Cheers
> 
> Mike Thomas.
> 
> 
> 
> 

-- 
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]