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: Mike Thomas
Subject: RE: [Gcl-devel] trying to finalize the windows issues ...
Date: Mon, 24 May 2004 14:00:57 +1000

Hi all.

| Could one of you three wonderful souls

Thanks, and also for the excellent suggestions.

| please try the two suggestions
| below (e.g. 1) patch,

Sadly, neither this patch alone nor in combination with 2) helps the Maxima
problem (but I was rushing so perhaps may have missed something).

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

Cheers

Mike Thomas.


|
| Take care,
|
| "Mike Thomas" <address@hidden> writes:
|
| > Hi Camm.
| >
| > | Greetings!  Mike, this sounds quite interesting and promising.
| > |
| > | The BEGIN/END NO_INTERRUPT macros only govern signal handling.  I'm
| > | trying at the moment to reproduce the signal capture in the maxima
| > | build that you must be seeing.  Do you have strace?  If so, can you
| > | post the results of running the maxima build under strace -f?
| > | Alternately,  can you break in main_signal_handler and/or before
| > | interrupt and provide a gdb backtrace?  What we may be seeing is that
| > | the Windows OS is sending signals to the running process that are
| > | simply not being seen on other systems.
| >
| > I should have known better as Windows doesn't do signalling as such -
| > they're faked up in the C runtime for the sake of compatibility
| which makes
| > the whole idea a bit doubtful.  Never-the-less it could have
| been a cause.
| > Further NO_INTERRUPT bracketing led to a regression rather than
| improvement
| > so although it may be that garbage collection interference is
| to blame I was
| > unable to catch a break in main_signal_handler.
| >
| > Can anyone think of another way for GC to occur while copying strings
| > around?
| >
|
| Your problem is symptomatic of some mishandling of gc in the static
| area or C stack.
|
| I note the following in main.c:
|
| #ifdef _WIN32
|           {
|             unsigned int dummy;
|
|             _stackbottom = (unsigned int ) &dummy;
|             _stacktop    = _stackbottom - 0x10000; // ???
|
|           }
| #endif
|
| Is it possible you are underestimating the C stack range, especially
| when the ASCI/PCL multi function/C stack consuming error reporting
| tree is in effect?

You are right about the C stack underestimation but it seems on my first
(but fairly rushed) tests not to be causing the Maxima problem.

It looks like the test could be simplified and made more accurate if tied up
with the ld --stack option during the build.  The default C stack is 22FF7C:

...
checking finding CSTACK_ADDRESS... got 2293628
...

which I confirmed with a small test program, and grows downwards.  The ld
docs at http://sources.redhat.com/binutils/docs-2.15/ld/Options.html#Options

say that:

"--stack reserve
--stack reserve,commit
Specify the amount of memory to reserve (and optionally commit) to be used
as stack for this program. The default is 2Mb reserved, 4K committed. [This
option is specific to the i386 PE targeted port of the linker]"

so in fact 65 K is a major underestimate.  Here is what GCL puts out just
before the check in main.c on the NULL_OR_ON_CSTACK macro check:

============================================================
GCL (GNU Common Lisp)  April 1994  131072 pages
core_end = 152ea000, Cnil = 6c1b60, &j = 22ff54, _stacktop = 2ff78,
_stackbottom = 22ff78
Building symbol table for c:/cvs/stable/gcl-2.6.1/unixport/raw_ansi_gcl.exe
..
rsym_nt: c:/cvs/stable/gcl-2.6.1/unixport/raw_ansi_gcl.exe rsym176
============================================================

I haven't time to bump this up to 8 M through the ld --stack option today.







reply via email to

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