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!mikejel@portal.uucp (John Little) (04/03/86)
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
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