[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] trying to finalize the windows issues ...
From: |
Camm Maguire |
Subject: |
[Gcl-devel] trying to finalize the windows issues ... |
Date: |
Sat, 22 May 2004 10:34:31 -0400 |
User-agent: |
SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigory ōmae) APEL/10.3 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI) |
Greetings!
Could one of you three wonderful souls please try the two suggestions
below (e.g. 1) patch, 2) more than 65k C stack, -> 8mb) re: the maxima
ignore-errors issue with --enable-debug and let me know what the
status is?
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?
Also, please give this a whirl:
Index: gbc.c
===================================================================
RCS file: /cvsroot/gcl/gcl/o/gbc.c,v
retrieving revision 1.13.4.2.2.10
diff -u -r1.13.4.2.2.10 gbc.c
--- gbc.c 7 May 2004 21:43:15 -0000 1.13.4.2.2.10
+++ gbc.c 18 May 2004 20:22:01 -0000
@@ -425,7 +426,7 @@
mark_contblock(cp, j);
} else if (x->a.a_displaced == Cnil) {
#ifdef HAVE_ALLOCA
- if (cp <= core_end) /* only if body of array not on C stack */
+ if (!NULL_OR_ON_C_STACK(cp)) /* only if body of array not on C stack */
#endif
x->a.a_self = (object *)copy_relblock(cp, j);}
else if (x->a.a_displaced->c.c_car == Cnil) {
Index: sgbc.c
===================================================================
RCS file: /cvsroot/gcl/gcl/o/sgbc.c,v
retrieving revision 1.9.4.1.2.11
diff -u -r1.9.4.1.2.11 sgbc.c
--- sgbc.c 7 May 2004 21:43:15 -0000 1.9.4.1.2.11
+++ sgbc.c 18 May 2004 20:22:01 -0000
@@ -313,7 +313,7 @@
;
else if (x->a.a_displaced == Cnil) {
#ifdef HAVE_ALLOCA
- if (cp <= core_end) /* only if body of array not on C stack */
+ if (!NULL_OR_ON_C_STACK(cp)) /* only if body of array not on C stack */
#endif
x->a.a_self = (object *)copy_relblock(cp, j);
}
Take care,
> Also improved bcopy() to allow for overlaps but alas no help either. I'm
> feeling defeated by this at the moment and out of ideas.
>
> Cheers
>
> Mike Thomas.
>
>
>
>
> _______________________________________________
> 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