jc@joker.mil.ufl.edu (Jim Castleberry) (01/09/91)
I've tracked down a problem in running zoo on the Tandy 6000 which causes it to create archives with bad crc's. Though the fix is somewhat obvious, I haven't seen it mentioned on the net, and I've seen others mention the problem with no solution, so I thought I'd post it. The problem is that the zoo "add" code uses *LOTS* of stack. In my test runs under adb 24k was not enough. The docs recommend using lots of stack, but the Tandy makefile, mkx68, has flags which result in the default 8k stack. The resulting underrun ends up trashing the static crc table but is not enough to cause a core dump, hence the crc errors. So, to fix it edit mkx68 to use a stack size of 32k by adding "-F 8000" to the "ldswitch=", then recompile. I also added "-DLINT" to the "cflags=" to cut the sccs strings out of the executable, but it will run with or without them. Enjoy! Jim
nanook@rwing.UUCP (Robert Dinse) (01/11/91)
In article <1991Jan9.093708.12518@eng.ufl.edu>, jc@joker.mil.ufl.edu (Jim Castleberry) writes: >I've tracked down a problem in running zoo on the Tandy 6000 which causes >it to create archives with bad crc's. Though the fix is somewhat obvious, >I haven't seen it mentioned on the net, and I've seen others mention the >problem with no solution, so I thought I'd post it. > >The problem is that the zoo "add" code uses *LOTS* of stack. In my test >runs under adb 24k was not enough. The docs recommend using lots of stack, >but the Tandy makefile, mkx68, has flags which result in the default 8k stack. >The resulting underrun ends up trashing the static crc table but is not >enough to cause a core dump, hence the crc errors. > >So, to fix it edit mkx68 to use a stack size of 32k by adding "-F 8000" >to the "ldswitch=", then recompile. I also added "-DLINT" to the "cflags=" >to cut the sccs strings out of the executable, but it will run with or >without them. > >Enjoy! > Jim 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.
jc@joker.mil.ufl.edu (Jim Castleberry) (01/13/91)
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.
jc@joker.mil.ufl.edu (Jim Castleberry) (01/16/91)
In article <1991Jan13.021726.14048@eng.ufl.edu> I wrote: > 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 Someone noticed that I dropped a 0 on the text address. 0x80000 should be 0x800000, so the 24-bit address space is divided in two. Jim.