segmentation violations

Brian R. Eckert brian at ctdi.UUCP
Thu May 4 00:52:10 AEST 1989


In article <2452 at lll-lcc.UUCP> scowles at wombat.UUCP (Sid Cowles) writes:
>i would like to compile the program month, rev 8.7, by mike morrell,
>[...]  i want to compile it for
>usage on a 286 machine so i am including the -M2 flag.  so far, every
>combination of flags i've used has resulted in a segmentation violation
>error when i run the load module
                      ^^^^^^^^^^^  ????? You show run time comments below

>various combinations of flags i've used are:
>flags:                          error messages:
>-M2                           | compiler: segment size exceeds 64K
>-M2l -Mt32  -LARGE            | run time: segmentation violation
>-M2l -Mt32  -LARGE -F 6000    | run time: segmentation violation
>-M2l -Mt128 -LARGE -F 6000    | run time: segmentation violation
>-M2he -Mt32 -LARGE            | compiler: infinite spill

Have you used a debugger to look at the a stack trace when this
thing dumps core?  It would probably provide some insight into
the problem.

I don't recall what -Mtnnn does and I'm not sure it really matters.
However, the infinite spill message is spit out when the compiler
can't grok a complex expression; this can be remedied by splitting
the expression up so as to produce several simpler expressions to
acheive the same result.

I should point out that -M2he is selecting huge model (a crock in
itself -- *if* it manages to produce code that runs, it's big
and sloooow) and enabled 'near' and 'far' keywords... you don't
need this.  I'd stick with large model.  Making code work on the
286 is not always done by typing make (as I'm sure you have
discovered)... I think you really need to look at that core dump
and find where it's trouble actually is, then make any adjustments
to the code that may be neccessary.  Usually you'll find it's some
sort of pointer problem like beleiving ints and pointers are
the same size (which they aren't on the 286).  I'm sorry I can't
offer better (perhaps someone else can add to this),  I haven't had
time to diddle with month (and besides,  I'm not using SCO).

>thanks,
>sid

Good luck!
-brian
-- 
Brian R. Eckert			|| uucp: brian at ctdi.UUCP
				||	 ...!uunet!cbmvax!ctdi1!ctdi!brian
Communications Test Design, Inc.||
West Chester, Pa.		|| Only entropy comes easy.



More information about the Comp.unix.xenix mailing list