[net.news] stack overflow with Usenet under Xenix/286

don@IMT3B2.UUCP (Don Kossman of SEI Information Technology) (03/29/86)

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
 -----------------------------------------------------------------------------

caf@omen.UUCP (Chuck Forsberg WA7KGX) (04/01/86)

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

dennis@rlgvax.UUCP (Dennis Bednar) (04/01/86)

> 
> 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

ben@catnip.UUCP (Bennett Broder) (04/02/86)

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}/

mike@rlgvax.UUCP (Mike Shaffer) (04/02/86)

> 
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

jerry@utrc-2at.UUCP (Jerry J. Deroo) (04/03/86)

> 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

dyer@spdcc.UUCP (Steve Dyer) (04/04/86)

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