Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!cbosgd!gatech!seismo!rlgvax!dennis
From: dennis@rlgvax.UUCP (Dennis Bednar)
Newsgroups: net.bugs.uucp,net.micro.pc,net.news,net.news.b
Subject: Re: stack overflow with Usenet under Xenix/286
Message-ID: <968@rlgvax.UUCP>
Date: Tue, 1-Apr-86 10:20:08 EST
Article-I.D.: rlgvax.968
Posted: Tue Apr  1 10:20:08 1986
Date-Received: Sat, 5-Apr-86 04:26:23 EST
References: <348@IMT3B2.UUCP>
Distribution: net
Organization: CCI Office Systems Group, Reston, VA
Lines: 44
Xref: watmath net.bugs.uucp:731 net.micro.pc:7639 net.news:4732 net.news.b:1349

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