Bernd Paysan wrote:
>
> On Monday 10 March 2003 14:11, Anton Ertl wrote:
> > =?ISO-8859-1?Q?Jorge_Acereda_Maci=E1?= wrote:
> > > I am doing some tests before packaging gforth for fink. This is what I
> > > get:
> > >
> > > $ ./configure CC=gcc2
> > > ...
> > > $ make
> > > ...
> > > ./gforth --die-on-signal -m 4M -p ".:~+:." -i kernl32b.fi -e 3
> > > exboot.fs -e 'fpath= .|~+|.' -e 's" mach16b.fs"' ./kernel/main.fs -e
> > > "save-cross kernl16b.fi- /usr/local/bin/gforth-0.6.0 bye"
> > > redefined NIL
> > > in file included from *the terminal*:0
> > > in file included from kernel/main.fs:92
> > > in file included from kernel/kernel.fs:24
> > > kernel/int.fs:733: CROSS: forward
> > > ['] cr catch if
> > > ^^
> > > Backtrace:
> > > $F4BA4 throw
> > > $362BCC c(abort")
> > > $3681D8 g>xt
> > > $368220 '
> > > $3621BC execute
> > > $3689E8 execute-exec-compile
> > > $368C20 tcom
> > > $368C9C ]
> > > $368D10 (:)
> > > make: *** [kernl16b.fi-] Error 1
> > >
> > > Any idea on what's going on there?
> >
> > I saw some Heisenbugs in earlier testing on big-endinan machines (on
> > several architectures and OSs). Thay always occured when building
> > kernel images, and did not produce a useful error message. After
> > adding "-e 3 exboot.fs", at least the last problem is solved. The
> > failures went away at the slightest provocation (e.g., adding (IIRC)
> > '-e "100 allocate 2drop"' as the first image option).
> >
> > Unfortunately, my latest tests did not reproduce this bug, either,
> > despite having 6 big-endian machines in my test base.
I have now found a way to reproduce the bug: just try various
allocates until it happens, like this:
for i in {0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}{0,5}; do echo $i; ./gforth
--die-on-signal -m 4M -p ".:~+:../gforth-0.6.0" -i kernl32b.fi -e 3 exboot.fs -e "$i
allocate 2drop" -e 'fpath= .|~+|../gforth-0.6.0' -e 's" mach16b.fs"'
../gforth-0.6.0/kernel/main.fs -e bye||break; done
With $i=095, the bug appeared (on a linux-ppc box), in the same form
as on Jorge's machine.
Letting this run a little longer, I see that the error happens when $i=
095 100 105 110 115
360
615 620
870 875
The runs seem to be about 256 bytes apart. A run length of 2 is
easily explained with 8-byte alignment of malloced regions, but the
095-115 run cannot be explained with that.
I also tried this on a little-endian machine, and saw no such
problems.
> > But maybe our cross.fs specialists can say more about that?
>
> Hm, the error indicates that CR is not defined before, and literals don't
> allow forward execution. Since this is clearly not the case (CR *is*
> defined before), we have to look why GFIND doesn't find it, or why it
> wasn't resolved when it was defined before.
Will you take a look at it? Do you have access to a big-endian
machine?
- anton
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
