Path: utzoo!attcan!uunet!samsung!rex!uflorida!eng.ufl.edu!joker.mil.ufl.edu!jc
From: jc@joker.mil.ufl.edu (Jim Castleberry)
Newsgroups: comp.sys.tandy
Subject: Re: zoo CRC problem on Tandy 6000:  FIX
Message-ID: <1991Jan13.021726.14048@eng.ufl.edu>
Date: 13 Jan 91 02:17:26 GMT
References: <1991Jan9.093708.12518@eng.ufl.edu> <214@rwing.UUCP>
Sender: news@eng.ufl.edu
Distribution: na
Organization: Machine Intelligence Lab, University of Florida
Lines: 50

In article <214@rwing.UUCP> nanook@rwing.UUCP (Robert Dinse) writes:
>In article <1991Jan9.093708.12518@eng.ufl.edu>, jc@joker.mil.ufl.edu (Jim Castleberry) writes:
> >The problem is that the zoo "add" code uses *LOTS* of stack.  In my test
> >...
> >The resulting underrun ends up trashing the static crc table but is not
> >enough to cause a core dump, hence the crc errors.
>     For what it's worth, both zoo and rzsz work fine with the default
>stack space if compiled with gcc instead of cc.
>
>     I am curious how not having enough stack space causes this error
>since I would expect it instead to cause core dumps.

Like I said, you don't get a core dump because the underrun is not
enough to hit the bottom of the data segment.  Consider the layout
of virtual memory when the program is running:
     -- -----------------
text |  |		|
 seg |  |	text	|
     -- ----------------- <-0x80000
     |  |	heap	|
     |  ----------------- <- _end + stack size (0x2000 default)
data |  |	stack	|
 seg |  ----------------- <- _end, the end of the data+bss
     |  |	bss	|
     |  -----------------
     |  |	data	|
     -- ----------------- <- 0x00000
The 6000 has only 2 virtual memory segments, one read-only for text and
one read-write for everything else.  You get a segmentation fault when
the stack wraps the bottom of the segment, but before it gets there it
stomps about on the data+bss.  In zoo there's enough data+bss that it
never wraps.

I've no idea what happens to the memory map when you have more than 1 meg
of RAM, so all this might change.  It's still limited to 2 segments, though,
so I'd expect it to stay about the same.  A smarter design would have put the
stack at the bottom (since it's fixed size anyway).  Then we'd only have to
worry about stack overrun which never (almost) happens.

As for it working with gcc, HOW?  If you look at zooadd.c, you'll see
an automatic array (which exists on the stack) of 4000 char ptrs.  At 4
bytes each that's almost 16k.  Does gcc use a larger default stack, or
does it get creative and put the array somewhere else?  Please find out
and post it!

BTW - I'm surprised you have gcc running on the 6000.  How high did you
have to set the max process size?  If there are any diffs to port it, how
about posting them, too.

Jim.