kayvan@mrspoc.Transact.COM (Kayvan Sylvan) (07/18/89)
I recently got the omega distribution and attempted to bring it up on
my Xenix 386 system.
I defined EXCESSIVE_REDRAW, STRING, and NORANDOM in odefs.h.
I had to include <sys/types.h> before <sys/file.h> in ofile.c and oscr.c
for it to compile.
It compiled fine. I run omega. I get the initial text. so far so good.
I roll a character. I type the character's name.
I get: "The City of Rampart." on my screen followed by a Segmentation
Violation.
Here's the sdb stack backtrace:
% sdb omega
642
*t
getspot(21,21,0), line 642
show_screen(), line 56
change_environment(2), line 1004
init_world(), line 374
main(1,25685008), line 327
_start()
*
Any ideas??? I'll be looking into it more tomorrow night.
---Kayvan
--
Kayvan Sylvan @ Transact Software, Inc. -*- Mountain View, CA (415) 961-6112
Internet: kayvan@Transact.COM -*- UUCP: ...!{apple,pyramid,mips}!mrspoc!kayvanross@contact.uucp (Ross Ridge) (07/21/89)
In article <KAYVAN.89Jul17220632@mrspoc.Transact.COM> kayvan@mrspoc.Transact.COM (Kayvan Sylvan) writes: >I recently got the omega distribution and attempted to bring it up on >my Xenix 386 system. I just installed omega, on a Xenix 386 system as well. >I had to include <sys/types.h> before <sys/file.h> in ofile.c and oscr.c >for it to compile. Me too. >It compiled fine. I run omega. I get the initial text. so far so good. >I roll a character. I type the character's name. > >I get: "The City of Rampart." on my screen followed by a Segmentation >Violation. Got that too. >Here's the sdb stack backtrace: (Luxury... I had to use adb to find the bug...) The problem is a compiler bug, it can't handle the level struct. I thought it was just a prob with our older compiler, but I looks like new ones have it too. The level struct (declared in odefs.h) looks like this: struct level { char depth; /* which level is this */ struct level *next; /* pointer to next level in dungeon */ #ifndef MSDOS struct location site[MAXWIDTH][MAXLENGTH]; /* dungeon data */ #else /* Over 64K worth of data! */ struct location *site[MAXWIDTH]; /* dungeon data */ #endif char generated; /* has the level been made (visited) yet? */ char numrooms; /* number of rooms on level */ char tunnelled; /* amount of tunnelling done on this level */ struct monsterlist *mlist; /* List of monsters on level */ int environment; /* where kind of level is this? */ int deepest; /*If level is dungeon head, deepest level made */ }; The problem is the site member being somewhat huge (98304 bytes on our system). When trying to access the members after site, the compiler generates incorrect code (it gets the offests wrong). The case that causes the core dump looks something like this: Level->environment = CITY; /* CITY == 2 */ which (incorrectly) generates code something like this: move [eax + 32784], 2 ^^^^^ this number is wrong The offset used isn't for Level->environment, but in fact is Level->site[21][21].thing (a pointer). This pointer then gets dereferenced in getspot and it dumps core. Finaly, the simple solution to the problem is to move the site member to the end of the struct, and it works ok. (In fact I suggest you do this even if you don't have this Xenix/386 problem, your compiler will probably generate better code.) Sorry, I can't provide diffs, I've hacked up the source too much to improve curses performance and so I could make it setuid. Ross Ridge -- l/ Hi! I'm a freem! ! Ross Ridge -- The Dreaded C64 User ! ross@contact [oo] ! ! ross@ziebmef -()- ! A glass of root-beer has half the ! rridge@watmath db ! alcohol as a loaf of bread. ! ross@watcsc