🚀 go-pugleaf

In article <348@IMT3B2.UUCP> don@IMT3B2.UUCP (Don Kossman of SEI Information Technology) writes:
>
>Having installed the usenet "B" package on our IBM-PC/AT running SCO-
>XENIX-286, we get an immediate "stack overflow, segmentation fault"
>message when we try to run "Vnews", or anything else, for that matter.
>
>We initially compiled using the suggested small impure model and the
>optimizer in 86 mode.  Large model and 286 mode doesn't help, nor does
>removing the optimizer option.  
>
>This is the Microsoft C compiler, by the way.
>
>
>Has anyone seen this problem?  Or is anyone else running SCO XENIX/286
>on an AT with usenet?   Help appreciated....

The Xenix documentation indicates the default stack arrangement is to
set the stack at the top of the data segment and allow it to grow down
until it meets the heap. 

Unfortunately, there does not seem to be any way to get Xenix to run
this way.  The default is a small fixed stack immediately above bss. 
The size if this fixed stack may be adjusted with the -F loader flag,
but there is no way to make it behave like the documentation promises
for the default case. 

Vnews is a lose on Xenix because there is no stack size spec that will
allow the database hashing program to handle a reasonable number of
articles. 

At Omen I am using rnews/inews and cunbatch for receiving articles. 
Although the machine has 2 MB ram, the Xenix C compiler huge model still
doesn't agree with compress, so we must limit our news feed's
compression to 12 bits. 

The news reader is "rn".  Each time I get a new C compiler I see if I
can compile rn with large model, but no luck so far.  I don't have a
spare man month or two to hack rn to get past the Xenix large model,
especially with a broken lint.  The small model version works, although
it runs out of memory and abends daily.  Fortunately, rn updates .newsrc
so one can start up another rn as many times as necessary to get through
the daily news. 

   Chuck Forsberg WA7KGX  ...!tektronix!reed!omen!caf   CIS:70715,131
   Author of Professional-YAM communications Tools for PCDOS and Unix
 Omen Technology Inc     17505-V NW Sauvie Island Road Portland OR 97231
Voice: 503-621-3406 TeleGodzilla: 621-3746 300/1200 L.sys entry for omen:
omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourly

> 
> Having installed the usenet "B" package on our IBM-PC/AT running SCO-
> XENIX-286, we get an immediate "stack overflow, segmentation fault"
> message when we try to run "Vnews", or anything else, for that matter.
> 
> We initially compiled using the suggested small impure model and the
> optimizer in 86 mode.  Large model and 286 mode doesn't help, nor does
> removing the optimizer option.  
> 
> This is the Microsoft C compiler, by the way.
> 
> 
> Has anyone seen this problem?  Or is anyone else running SCO XENIX/286
> on an AT with usenet?   Help appreciated....
> 
> Don Kossman at SEI Information Technology, Los Angeles.
> 
> 
> 
> 
>  -----------------------------------------------------------------------------
>  email	: ...IMT3B2!don 	| Don Kossman of SEI Information Technology
>  data	: +1 714 855 6647	| Mission Viejo, California
>  -----------------------------------------------------------------------------

Yes we have run into the same problem but with different application
(NOT vnews) software. The basic problem is that Xenix ALWAYS makes ds = ss.
By this I mean that the data segment and the stack segment ALWAYS share the
same physical 64k block of memory. The only hope that you have of getting
around the problem you are seeing is to try using the -F option when
linking (ld) the object modules. This option allows you to increase the
stack size beyond the default 4096 (note that the documentation states that
without the -F you receive a variable stack which can grow to 64K...DON'T
BELIEVE THIS...TAKE A LOOK AT param.h). If you eventually need to define a
stack size such that you get a too big error when attempting to execute
the resulting program then welcome to the club. When you have reached the
point that you can either get a stack overflow or the too big error but
not a runnable program you have reached the roadblock of ss = ds which I
mentioned earlier. At this point you are out of luck unless you have a
brother, friend, wife, etc who works for SCO. We are now in this situation
and SCO has shown no desire to correct their compiler bugs.

Mike Shaffer CCI, Reston Va.
Ph: 703/648-3313

In article <348@IMT3B2.UUCP>, don@IMT3B2.UUCP (Don Kossman of SEI Information Technology) writes:
> 
> Having installed the usenet "B" package on our IBM-PC/AT running SCO-
> XENIX-286, we get an immediate "stack overflow, segmentation fault"
> message when we try to run "Vnews", or anything else, for that matter.
> 
> We initially compiled using the suggested small impure model and the
> optimizer in 86 mode.  Large model and 286 mode doesn't help, nor does
> removing the optimizer option.  
> 
> This is the Microsoft C compiler, by the way.

Just use the -F flag to specify a larger stack.  I used -F 2000 and haven't
had a stack overflow since.

-- 

Ben Broder
{ihnp4,decvax} !hjuxa!catnip!ben
{houxm,topaz}/

> 
I now have an update to the continuing saga of Xenix stack overflows.
We have managed to get hooked up with the right people within SCO. Today
we will be receiving a beta version of the next release of the SCO C
compiler. It turns out that SCO IS aware of some of the problems with
the C compiler and ARE taking steps to correct it. In addition, SCO has
asked us to work with them in resolving remaining compiler problems. Due
to the fact that we are probably asking more of the compiler than 99% of
the present Xenix users, it should develop into a fairly bullet proof product.

Mike Shaffer CCI, Reston Va. ..rlgvax!mike

I had similar problems with IBM XENIX on the AT with large model
programs.  The linker tried to glue the data and stack segments together,
and frequently ran out of room.  I worked around the problem by making
many of my data structures very large (close to 64 K) so that there
was no room to put the stack in with the data.  For example, 1K arrays
became 62K arrays.  When the linker merges enough items to fill a 64K
segment, it starts a new one.  By making as many objects as large as possible,
you increase the chance of having enough space for the stack.
Of course, this only works if you have lots of memory.
Looking at the map is slightly useful, but expect lots of trial and
error until you link everything together and it all works.

John Little
sun!portal!jel

> Having installed the usenet "B" package on our IBM-PC/AT running SCO-
> XENIX-286, we get an immediate "stack overflow, segmentation fault"
> message when we try to run "Vnews", or anything else, for that matter.
> 

this is yet another example of posted code's "all the world is a vax"
syndrome.

I have run into the same thing on Plexus machines, and Pixels, and an
Elxsi 6400 as well.

I got around it by looking for all large structures and arrays that
were declared as dynamic variables in a function.. move their
declaration outside the function body, maybe change the name, etc.

(this is an AT runing Xenix 3.0)

source code is available...email me
-- 
      Jerry J. Deroo
      utzoo!yetti!utrc-2at!jerry

I have had absolutely *NO* problems using 'rn' on SCO XENIX 286
having compiled it as a medium model program and it has never
dumped core on me.  Of course, if it all fits in a single split
I&D text segment, I suppose there's no advantage to running in
medium mode.  Maybe I just read fewer news groups than you??
-- 
Steve Dyer
dyer@harvard.HARVARD.EDU
{bbncca,bbnccv,harvard,ima,ihnp4}!spdcc!dyer